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(54) Method and apparatus for route optimisation in nested mobile networks 


(57) A method of transmitting a data packet on a 
communication path from a first communication node 
(CN1,CN2) to a second comminucation node 
(LFN 1 ,LFN2) in a mobile network (11 5). The method In- 
cludes receiving a route message (1 01 0,1 020) from the 
second communication node (LFN1 ,LFN2), wherein the 
route message (1010,1020) includes a list of intemnedi- 
ary addresses ({MR1,COA},{MR1-COA,MR2-COA}) 
between the first communication node (CN1,CN2) and 


the second communication node {LFN1,LFN2). A pre- 
ferred communication path is generated In response to 
the list of Intermediary addresses; and at least one data 
packet is transmitted from the first communication node 
(CN1,CN2) to the second communication node 
(LFN1 ,LFN2) via this preferred communication path. 

In this manner, an optimised data path is deter- 
mined in order to send at least one data packet to an 
intended recipient (LFN1 ,LFN2), for example in a nest- 
ed mobile network scenario. 
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Description 

Field of the Invention 

[0001] This invention relates to telecommunication 
systems In which data flows between mobile nodes, for 
example personal digital assistants with wireless com- 
munication capability, and a data network, for example 
the Internet. 

Background of the Invention 

[0002] The Internet Is becoming more and more pop- 
ular, and users increasingly wish to access the Internet 
whilst on the move. Different types of mobile nodes (i. 
e. mobile communication units) may be employed for 
this purpose, for example a mobile telephone or a per- 
sonal digital assistant (PDA) with wireless communica- 
tion capability. 

[0003] Increasingly, mobile users are accessing the 
Internet via different types of fixed or wireless access 
networks, for example a cellular radio communication 
network, such as a Universal Mobile Telecommunica- 
tion System (UMTS) network, a Hlper1_AN/2 or IEEE 
802.11b local area network, a Bluetooth local commu- 
nication system, orfixed accesses such as the Ethernet, 
and so on. The data route between the mobile node and 
the Internet further comprises an Intemet protocol sub- 
net (IP subnet), such that the route is as follows: mobile 
node - access network - IP subnet - Intemet (and re- 
verse order for the data route from the Internet to the 
mobile node). 

[0004] It is currently possible to seamlessly handover 
accessing of the Intemet from one access network to 
another, for example by using a protocol known as Mo- 
bile-IP 

[0005] Traditional mobility support aims to provide 
continuous Internet connectivity to mobile hosts, there- 
by allowing individual mobile users to connect to the In- 
ternet whilst being mobile and moving their Internet ac- 
cess location. In contrast, network mobility support is 
concerned with situations where an entire network 
changes its point of attachment to the Intemet topology 
and thus Its accessibility in the topology. Such a network 
in movement can be called a Mobile Network. 
[0006] There exist a large number of scenarios where 
such Mobile Networks exist. For example, a Personal 
Area Network (PAN, i.e. a network of several personal 
devices attached to an individual) is known whereby the 
PAN changes its point of attachment to the Internet to- 
pology whilst the user is walking in a shopping mall. In 
addition, a network may be embedded in a bus or air- 
craft, providing on-board Intemet access to passengers. 
A passenger may use a single communication device 
(e.g. a laptop) or be itself a Mobile Network (e.g. a PAN). 
Notably, this configuration illustrates a case of a Mobile 
Network visiting a Mobile Network (i.e. nested mobility). 
[0007] As such, a Mobile Network can be defined as 


a set of nodes composed of one or more IP-subnets at- 
tached to a Mobile Router (MR). These IP subnets may 
also be viewed as a mobile unit, with respect to the rest 
of the Internet, i.e. a MR and all its attached nodes (so 

5 called Mobile Network Nodes or MNNs). 

[0008] A document [1] authored by Thierry Ernst, 
Hong- Yon Lach, IETF Internet-Draft draft-emst-monet- 
tenninology-00.txt, February 2002, describes a list of 
definitions for the Mobile Network terminology that can 

10 be applied in this application. In particular, the following 
temris may be defined as follows: 

(i) A Local Fixed Node (LFN): 

*5 A node permanently located within the Mobile 

Network and that does not change its point of 
attachment. A LFN can either be a Local Fixed 
Host (LFH) or a Local Fixed Router (LFR). 

20 (ii) A Local Mobile Node (LMN): 

A local mobile node is one that belongs to the 
Mobile Network and changes its point of attach- 
ment from a link within the Mobile Network to 
25 another link within or outside the Mobile Net- 

work. In this regard. It can be assumed that the 
home link of the LMN is a link within the Mobile 
Network. A LMN can either be a Local Mobile 
Host (LMH) or a Local Mobile Router (LMR). 

30 

(iii) A Visiting Mobile Node (VMN): 

A VMN is one that does not belong to the Mobile 
Network, and changes Its point of attachment 
35 from a link outside the Mobile Network to a link 

within the Mobile Network (i.e. the home link of 
the VMN is not a link within the Mobile Net- 
work). A VMN that attaches to a link within the 
Mobile Network obtains an address on that link. 

40 A 

VMN can either be a Visiting Mobile Host 
(VMH) or a Visiting Mobile Router (VMR). 

(h/) A Mobile Network Prefix: 

45 

A bit string that consists of a number of initial 
bits of an IP address, which identifies a Mobile 
Networi< within the Internet topology. Nodes be- 
longing to the Mobile Network (i.e. at least MR, 
so LFNs and LMNs) share the same IPv6 "networi< 

identifier". For a single mobile IP-subnet, the 
Mobile Network Prefix is the "networic identifier" 
of this subnet. 

55 (v) An Egress Interface of a MR: 

This is the interface attached to the home link 
if the Mobile Network Is at home. Alternath/ely, 
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It is the Interface attached to a foreign link If the 
Mobile Network Is In a foreign network. 

(vl) An Ingress Interface of a MR: 

This is the Interface attached to a link inside the 
Mobile Network. The concept of egress and in- 
gress interfaces can be extended to other types 
of nodes within a mobile network as follows: 

(a) All network interfaces of hosts (fixed or 
mobile) in a mobile network are said to be 
egress interfaces. None of them is said to 
be an ingress interface. 

(b) A fixed router in a mobile network (i.e. 
LFR) may have several egress and ingress 
interfaces. The type of each interface 
should be pre-configured on such routers. 
An egress interface is usually an interface 
on the shortest path to a Mobile Router. A 
fixed router in a mobile network should 
have at least one egress interface. 

(vii) A MR may have multiple Egress and Ingress 
interfaces. 

(viii) A mobile network may have multiple MRs. 

[0009] Recently, there has been a lot of interest and 
research Into the Mobile IPv6 specification, as de- 
scribed in the document [2] authored by David B. John- 
son: IETF Internet-Draft draft-letf-mobileip-ipv6-15.txt, 
July 2001 . A major concern with Mobile ipv6 is that the 
research has proven that the iPv6 standard is currently 
unable to adequately address network mobility. In par- 
ticular, the document [3] authored by Thierry Ernst and 
Hong-Yon Lach: IETF Internet-Draft draft-ernst-mo- 
blleip-v6-network-02.txt, June 2001 , details problems 
encountered with Mobite-IPv6 in supporting Mobile Net- 
works. 

[0010] In summary, it has been determined that even 
if a MR's Home Agent (HA) is able to intercept packets 
addressed to MNNs that are operating behind the MR, 
the MR's HA is clearly unable to encapsulate them to 
the care-of-address of the appropriate MR. Note that 
every data packet has a source address and a destina- 
tion address. A tunnelled packet is a packet that encap- 
sulates in it another packet. Thus, the encapsulating 
packet has a pair of source and destination addresses. 
A further encapsulated packet has additional source 
and destination addresses. 

[0011] The lack of knowledge of a true location of a 
particular MNN results from the HA not knowing any 
(never mind a preferred) data route to the Mobile Net- 
work, once it has moved to a Visited' location. Unfortu- 
nately, when a MR registers with its HA the MR only in- 
fornis the HA to record a host-specific route in its routing 
table. The inventors of the present invention have rec- 


ognised that a preferred network route generated using 
the mobile network address (prefix, prefix length and 
care-of-address) of the appropriate MR would greatly 
assist in this matter. 

5 [0012] In the field of this invention, the Mobile IPv4 
specification, detailed In [4] C. Perkins, IETF RFC 3220, 
"IP Mobility Support for IPv4", Standards Track, January 
2002, describes how Network Mobility can be supported 
in the case of IPv4 mobility. However, it has also been 

10 detemnined that IPv4 does not support route optimisa- 
tion for MNNs behind the MR. 

[0013] Thus, all the (incoming and outgoing) traffic be- 
tween a MNN and its corresponding nodes (CNs) is 
passed to the MR's Home Agent. This problem is exac- 
ts erbated in the case of nested mobility, which is where a 
CN wishes to pass data to a MNN that Is behind a 
number of MR links, or a mobile node visiting a mobile 
network. In the case of nested mobility, the packet will 
thus be encapsulated several times as a result of being 
20 routed through all of the Home Agents of all the nested 
MRs. This is clearly inefficient routing. 
[001 4] Similarly, In the case of 1 Pv6, the document [5] 
authored by T. J. Kniveton: IETF Internet-Draft draft- 
kniveton-mobrtr-00.txt, November 2001 describes how 
25 to support mobile networks with no modifications to Mo- 
bile IP (v4 or v6). The mechanism proposed to address 
the support of nested mobility is described with respect 
to FIG. 2. It suffers from the same problem of multiple 
tunnelling by the Home Agents of the nested mobile 
30 routers as described in the previous paragraph. When 
a MR, for example MR2 260, has attached to a visited 
network 110 (via another Mobile Network MR1 link), a 
bi-directional tunnel 210, 215, 220 Is established be- 
tween MR2 260 and its HA - HA2 250. When a node, 
35 for example LFN2 165, is attached to MR2 260 and 
wishes to send an IP packet to a CN, say CN2 255, via 
the Internet 115, that packet is tunnelled by MR2 260 (to 
HA2 250) and again by MR1 150 (to HA1 240). The mul- 
tiple-tunnelled data packet is then passed to the HA of 
40 the latest MR to tunnel the data, namely to HA1 240. 
HA1 240 then f onwards It to the intended recipient CN2 
255 via the source MR's HA, namely HA2 250. 
[0015] This proposed data routing method, and the 
problems associated with it, are best described by way 
45 of an example. Thus, let us assume that LFN2 165 
sends a data packet to CN2 255. The data packet Is first 
routed 205 towards MR2 260. The data packet Is then 
tunnelled by MR2 260 to be sent to HA2 250. This tun- 
nelling process of the data packet from MR2 260 to HA2 
50 250 is Itself, by necessity, first routed 210 towards its 
linked MR, namely MR1 150. MR1 150 further tunnels 
the data and fonvards 215 the multiple-tunnelled packet 
to Its HA, namely HA1 240. HA1 240 de-tunnels the data 
packet, as tunnelled by MR1 150 and forwards 220 the 
55 partially de-tunnelled packet to its original intended re- 
cipient, HA2 250. HA2 250 further de-tunnels the pack- 
et, as tunnelled by M R2 260, and f onvards 225 the whol- 
ly de-tunnelled data packet to CN2 255. 
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[0016] Clearly, the solution proposed does not pro- 
vide any support for route optimisation, since both in- 
bound and outbound packets are routed through the 
Home Agent of both MRs 1 50, 260. In fact, packets from 
CN2 255 addressed to LFN2 165 will follow the same 5 
path (in reverse order) and will then be encapsulated by 
each Home Agent 240. 250 of each of the nested MRs 
150, 260. Once again, this Is clearly inefficient routing, 
particularly for a practical situation whereby there may 
be many more than two levels In the nested network. 
[0017] The solution presented in a document au- 
thored by Thierry Emst and Hong-Yon Lach: IETF Inter- 
net-Draft draft-ernst-moblleip-v6-network-02.txt, June 
2001 , proposes a means for supporting network mobility 
in the framework of Mobile IPv6. This solution introduc- 
es the following concept: when a Mobile Router roams 
to a visited network, it sends a Prefix Scope Binding Up- 
date to its Home Agent (HA). Unlike a classlcai Mobile 
IPv6 Binding Update message, a Prefix Scope Binding 
Update does not bind a home address with a care-of 
address. 

[0018] In contrast, the MR Prefix is bound with the MR 
care-of address, for a particular MR. Upon reception of 
a packet whose prefix matches with the MR prefix, the 
Home Agent must then tunnel the packet to the MR 
care-of-address that has been Identified as being able 
to deliver the tunnelled packet to the intended recipient. 
Likewise, a MR may send prefix-scope BUs to the cor- 
responding nodes of the nodes it serves. This solution 
brings a more efficient support of mobile networks to 
Mobile ii=V6, since it may provide a limited improvement 
to route optimisation. 

[0019] However, the scope of this draft has explicitly 
excluded the case of nested mobility, which presents a 
significant hurdle to efficient route optimisation. As such, 
the solution proposed in the Thierry Ernst document, 
IETF Intemet-Draft draft-emst-moblleip-v6-network- 
02.txt, June 2001, fails to provide a useful solution to 
route optimisation in many practical situations. Again, 
the problems that emanate from this document, partic- 
ularly in the case of nested mobility, are best highlighted 
in an example situation. 

[0020] Referring now to FIG. 3, a mechanism for rout- 
ing data packets in an IPv6 networic using the proposal 
of Thierry Emst IETF Intemet-Draft draft-ernst-mo- 
biielp-v6-network-02.txt, June 2001 . Notably, the prob- 
lems emanating from using this mechanism In a nested 
mobility are highlighted. 

[0021] A mobile router MR1 150 is attached to a vis- 
ited link 110. A mobile router MR2 260 is attached to 
MR1 's link 155. A local fixed node LFN2 1 65 is attached 
to MR2's link 230. Again, let us assume that LFN2 165 
is attempting to communicate with a corresponding 
node CN2 255. 

[0022] Let us further assume that, at the beginning of 
the simple scenario detailed in FIG. 3, MR1 150 and 
MR2 260 have already sent BU messages to their re- 
spective HAS 240, 250. That is, HA1 240 knows that 


MR1 's 1 50 prefix is reachable at MR1 's care-of address. 
Similarly, H A2 250 knows that MR2's 260 prefix is reach- 
able at MR2's care-of address. 

[0023] When a data packet is sent from CN2 255 to 
LFN2 165, CN2 255 has no knowledge about LFN2's 
1 65 actual location. Thus, the data packet that it sends 
Is therefore routed 325 towards home link-2 105. HA2 
250 Intercepts the data packet and tunnels it to MR2's 
care-of address. This can be understood, as HA2 250 
knows that MR2's prefix is reachable at MR2's care-of 
address. 

[0024] This tunnelled packet (from HA2 250 to MR2's 
260 care-of address) Is routed 320 toward link-1 245, 
since MR2*s 260 care-of address matches MR1's 150 
prefix. HA1 240 intercepts the data packet and tunnels 
it to MR1 's care-of address, namely towards the visited 
link 110, since HA1 240 knows that MRVs prefix is 
reachable at MRI's care-of address. 
[0025] MR1 150 then de-tunnels the data packet re- 
ceived from HA1 240. MR1 150 then fonwards the con- 
tent to the original recipient, MR2 260. Meanwhile, MR1 
1 50 sends a Binding Update to the sender of the encap- 
sulated packet (that is HA2 250) to Infomn it that MRI's 
prefix Is reachable at MR1 's care-of address. Note that 
from MRI's point of view, HA2 250 is a Correspondent 
Node and not its Home Agent (i.e. the 'H' bit in the BU 
is not set). It Is up to the HA2 250 to accept this Binding 
Update or not. 

[0026] MR2 260 de-tunnels the data packet that it re- 
ceived (I.e. the portion of the data packet that had been 
encapsulated by HA2 250) and forwards the content 
(the initial packet from CN2 255) to LFN2 165. Mean- 
while, MR2 260 sends a Binding Update message to the 
sender of the encapsulated packet (that Is, CN2 255) to 
infomn it that MR2*s prefix (covering the LFN2 165 ad- 
dress) is reachable at MR2's care-of address. This In- 
fonnation is stored in the CN's binding cache 370, 
[0027] Once an initial packet has reached its destina- 
tion, transmission of a second or subsequent packet 
from CN2 255 to LFN2 1 65 leads to the scenario depict- 
ed in FIG. 4. After having reviewed its binding cache 
370, CN2 255 recognises that LFN2 1 65 Is reachable at 
MR2's care-of address. 

[0028] Thus, it sends the data packet to MR2's care- 
of-address with a routing header for LFN2 165. MR2's 
care-of-address belongs to MRI's link and is therefore 
routed towards Home Link-1 245. In this manner, a mi- 
nor improvement to route optimisation Is achieved by 
the bypassing of the transmission of the data packet to, 
and from, HA2 250. 

[0029] HA1 240 then intercepts the data packet and 
tunnels the packet to MR1 's care-of address, since HA1 
240 knows that MR1 ' prefix is reachable at MR1 's care- 
of address. 

[0030] MR1 150 de-tunnels the packet from HA1 240 
and f onwards the content to the mobile router MR2 260 
of the originally intended recipient, LFN2 165. Mean- 
while, MR1 150 sends a Binding Update to the sender 
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of the encapsulated packet (that is» CN2 255) to inform 
it that MRVs prefix is reachable at ly^RVs care-of ad- 
dress. 

[0031] When receiving the originai paclcet as sent by 
CN2 255, MR2 260 replaces its address in the destina- 
tion field of the packet with the address contained in the 
routing header (that is, LFN2 1 65) and forwards the data 
packet to the ultinnate recipient. 
[0032] The inventors of the present Invention have 
identified a significant problem with the scenario depict- 
ed in FIG. 4. Ail subsequent packets from CN2 255 to 
LFN2 1 65 will be routed in exactly the same manner as 
the second data packet. That is, there will be no subse- 
quent improvement towards route optimisation. This Is 
more clearly shown in respect of FIG. 5. 
[0033] Referring now to FIG. 5, a known binding 
cache 500 Is illustrated. The binding cache comprises 
a list of entries, specific to each MR in a nested mobility 
scenario. The binding cache entries include, for exam- 
ple a MR3 prefix and prefix length 530, with a link 532 
to a determined MRS care-of -address 534, if one has 
been determined. The MR3 entry 535 is linked 536 to 
the next entry in the binding cache, namely that for MR2. 
The MR2 prefix and prefix length 520, includes a link 
522 to a detennined MR2 care-of-address 524, if one 
has been detemnlned. A similar arrangement and link 
526 is perfonned to MR1 , and so on. 
[0034] In addition, the binding cache entries include 
a flag entry (not shown). A 'P' flag is the "Prefix Scope 
Registration" flag. When it is set, a "Home Address" field 
is filled with the Mobile Networi< prefix (the prefix that is 
advertised by the Mobile Router) and the "Prefix Length" 
corresponds to the length of the Mobile Networi< prefix. 
[0035] It is specified in the document by Thierry Emst: 
IETF Internet-Draft draft-ernst-mobileip-v6-network- 
02.txt, June 2001 , that the Binding Cache is searched 
for an entry corresponding to the destination address of 
the packet In one pass. As a result of the search, either 
nothing has been found (no entry), or the full address 
has been found (128-bit match for an IPv6 address, P 
flag unset), or the first bits of the destination address 
match with a registered prefix for the registered prefix 
length. In the latter case, the destination is located in a 
mobile networi<. 

[0036] Therefore, with reference to FIG . 4, when CN2 
255 has to send a packet to LFN2 165, CN2 255 still 
reviews its binding cache and finds the entry 'MR2 260 
prefix reachable at MR2 260 Co@' 520, 524. CN2 255 
does not even considerthe entry 'MR1 150 prefix reach- 
able at MR1 Co@' 510, 514, as this would appear to 
have no bearing on the LFN2 address. The Inventors 
have recognised that this deficiency results from the 
LFN2 165 address being unrelated to the MR1 prefix. 
The fact that MR2 260 Co® belongs to MR1 prefix is 
neither seen, nor even used by CN2 255. 
[0037] Consequently, the only optimisation that the 
Thienry Ernst proposal can support is related to the HA 
(HA2 250) of the MR (MR2 260) serving the communi- 


cating MNN (LFN2 165 In the above example). This so- 
lution describes indeed a means for having packets be 
sent directly from CN2 255 to HA1 240, Instead of CN2 
255 to HA2 250 and thereafter to HA1 240. However, if 

5 there were n successive levels of nested mobility, this 
solution provides minimal route optimisation, no more 
than having a CN2 255 -> HAn.^ -> HA1 

path instead of CN2 255 HAj, HA^.^ HA^^g ... 
-> HA1 path. This proposal is therefore still cleariy inef- 

10 ficient, particularly in the case of nested networks. 
[0038] A need therefore arises for a mechanism, ap- 
paratus and associated methods to support route opti- 
misation in Networi< mobility, especially in the case of 
IPv6. In particular, a need has arisen to support route 

IS optimisation in the case of nested mobility, wherein the 
aforementioned problems are substantially alleviated. 

Statement of Invention 

20 [0039] In accordance with a first aspect of the present 
invention, there is provided a method of transmitting a 
data packet from a first communication node to a second 
communication node in a mobile network, as claimed in 
Claim 1 . 

2s [0040] In accordance with a second aspect of the 
present invention, there Is provided a communication 
message, as claimed in Claim 13. 
[0041] In accordance with a third aspect of the present 
invention, there is provided a communication message, 

30 as claimed in Claim 14. 

[0042] In accordance with a fourth aspect of the 
present invention, there is provided a communication 
message, as claimed In claim 1 6. 
[0043] In accordance with a fifth aspect of the present 

35 invention, there is provided a communication node, as 
claimed in Claim 17. 

[0044] In accordance with a sixth aspect of the 
present invention, there is provided a communication 
node, as claimed In Claim 1 8. 
40 [0045] In accordance with a seventh aspect of the 
present invention, there is provided a storage rnedlum, 
as claimed in Claim 19. 

[0046] In accordance with an eighth aspect of the 
present Invention, there is provided a method for bulld- 

45 ing an extended binding cache, as claimed in claim 20. 
[0047] In accordance with a ninth aspect of the 
present invention, there is provided a method for con- 
structing and sending a care-of route advertising mes- 
sage at a mobile networi< node, as claimed in Claim 21 . 

50 [0048] In accordance with a tenth aspect of the 
present Invention, there is provided method for con- 
structing and sending mobile networic prefix advertising 
message at a mobile router, as claimed In Claim 22. 
[0049] In accordance with an eleventh aspect of the 

55 present invention, there Is provided a storage medium, 
as claimed in Claim 23. 

[0050] In accordance with a twelfth aspect of the 
present invention, there is provided an apparatus, as 
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claimed in Claim 24. 

[0051] In accordance with a thirteenth aspect of the 
present invention, there is provided a communication 
unit, as claimed in Claim 25. 

[0052] In accordance with a twelfth aspect of the 
present invention, there is provided a communication 
system, as claimed in Claim 26. 
[0053] Further aspects of the present invention are as 
claimed In the dependent Claims. 

Brief Description of the Drawings 

[0054] 

FIG. 1 1llustrates the movement of a IVIobile Network 
in an Internet; 

FIG. 2 Illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 

mobility; 

FIG. 3 Illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 
mobility that highlights the inefficiency of the data 
routing; 

FIG. 4 illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 
mobility that highlights the inefficiency of an im- 
proved process of the data routing; and 

FIG. 5 Illustrates a known binding cache for routing 
data packets in mobile node networks. 

[0055] Exemplary embodiments of the present inven- 
tion will now be described, with reference to the accom- 
panying drawings, In which: 

FIG. 6 illustrates a network topology for advertising 
a mobile router mobility within mobile networks, in 
accordance with the pretended embodiment of the 
present invention; 

FIG. 7, FIG. Sand FIG. 9 illustrate flowcharts for an 
MNN router constructing and sending a care-of 
route advertisement, in accordance with the pre- 
ferred embodiment of the present invention; 

FIG. 10 illustrates a network topology for sending 
extended BUs to CNs in accordance with the pre- 
fenred embodiment of the present Invention; 

FIG. 11 Illustrates a flowchart of an MNN generating 
a care-of route, in accordance with embodiments of 
the present invention; 

FIG. 12 and FIG. 13 Illustrate flowcharts of an MNN 
sending extended BU messages to ite CN(s) (and 


HAs), in accordance with the prefen'ed embodiment 
of the present Invention; 

FIG. 14 and FIG. 15 illustrate flowcharts of a MNN 
5 sending an extended BU to its CN{s) (and its HAs) 
in accordance with the pretended embodiment of the 
present invention; 

FIG. 1 6 illustrates a flowchart of a dynamic discov- 
10 ery method of a mobile network prefix for a MNN in 
a mobile network, in accordance with the prefenred 
embodiment of the present invention; 

FIG. 17, FIG. 18, and FIG. 19 illustrate flowcharts 
15 of processes of MNN routers sending a mobile net- 
work prefix advertisement message, In accordance 
with the preferred embodiment of the present inven- 
tion; 

20 F1G.20 illustratesaflowchartof a first node sending 
a data packet to a second node, in accordance with 
the preferred embodiment of the present invention; 

FIG. 21 illustrates pref en-ed examples of data pack- 
25 et fomnats sent by a first node to a second node, in 
accordance with embodiments of the present inven- 
tion; 

FIG. 22 and FIG. 23 illustrate a mobile network pre- 
30 fix solicitation message and a mobile network prefix 
advertisement message respectively, in accord- 
ance with the prefen^d embodiment of the present 
invention; 

35 FIG. 24 and FIG. 25 illustrate a care-of route solic- 
itation message and a care-of route advertisement 
message respectively, in accordance with the pre- 
ferred embodiment of the present invention; 

40 FIG. 26 and FIG. 27 illustrate an extended BU mes- 
sage sent from a LFN and a VMN respectively. In 
accordance with the preferred embodiment of the 
present Invention; 

45 FIG. 28 illustrates an extended binding cache in ac- 
cordance with the preferred embodiment of the 
present invention; 

FIG. 29 illustrates the construction of a care-of- 
50 source route from a received extended BU in ac- 
cordance with the preferred embodiment of the 
present Invention; and 

FIG. 30 is a flowchart that illustrates a process of a 
55 first node receiving an extended BU from a second 
node in accordance with embodiments of the 
present invention. 
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Description of Preferred Embodiments 

[0056] There is currently no standard mechanism to 
support Network mobility adequately, particularly in the 
case of IPv6 for nested mobility data networks. In par- 
ticular, there is no provision or support for route optimi- 
sation. 

[0057] This is a major issue, as nested mobility is a 
very realistic scenario for Mobile Router applications. In 
addition route optimisation is much more important with 
regard to movement of a Mobile Network, than for move- 
ment of a single Mobile Node, since the amount of traffic 
handled is much greater. 

[0058] The preferred embodiment of the present in- 
vention is described with respect to route optimisation 
in transmitting at least one data packet between a cor- 
responding node (communication unit) and a local fixed 
node (or vice versa). In this context, route optimisation 
may be viewed as "the-shortest-path" direct communi- 
cation between a Mobile Network Node (MNN) and its 
Correspondent Nodes (CNs), particularly for an MNN 
within a Mobile Network where a nested mobility (Mobile 
Networks visiting Mobile Networks) scenario exists. 
[0059] It is envisaged that the corresponding node 
may be any communication unit capable of sending a 
data packet across a data network (such as the Inter- 
net), for example, a web server, a PC, or a workstation 
running a web server such as www.vahoo.com, etc. The 
CN may also be any mobile data communication unit 
such as a general packet radio system (GPRS) device 
or a 3"^ generation (3G) cellular phone, a personal dig- 
ital assistant (PDA), etc., connected to the data network 
through any type of access. Note that the CN may also 
itself be located in a mobile network. 
[0060] As explained in the previous section, a Mobile 
Router (MR) must send a Binding Update (BU) message 
to its Home Agent (HA) when moving to a Foreign Net- 
work. By sending a BU message to its HA, the MR main- 
tains IP reach-ability for itself as well as for nodes it 
serves (MNNs). 

[0061 ] Jn accordance with the preferred ernbodiment, 
no restriction is placed on the mechanism to be used by 
the Mobile Network to inform its Home Agent about its 
new location. In this regard, any known approach such 
as those described in [3] Thierry Ernst, Hong-Yon Lach, 
IETF Internet-Draft draft-ernst-mobileip-v6-network- 
02.txt, June 2001, or [5] T. J. Kniveton, IETF Internet- 
Draft draft-kniveton-mobrtr-OO.txt, November 2001, 
may be adapted and used. The adaptation of such tech- 
niques enables route optimisation to be achieved in cas- 
es of nested Mobility. 

[0062] Furthennore, in an enhanced embodiment of 
the present invention, it is shown how the approaches 
in [3] Thierry Ernst, IETF Internet-Draft draft-ernst-mo- 
bileip-v6-networic-02.txt, June 2001 , and [5] may be lev- 
eraged in order to also achieve route optimisation on the 
path HA -> MN (where MN is either a host or a router). 
[0063] The preferred embodiment of the present in- 


vention utilises three key concepts, which are used ei- 
ther singly or preferably In combination. The three key 
concepts are: 

5 (i) Advertising a Mobile Router's mobility within its 
Mobile Network. 

(ii) Sending of one or more extended Binding Up- 
date messages by MNNs to their respective CNs. 

10 An extended Binding Update message sent by a 
MNN would include a "care-of route" instead of a 
single care-of address in vanilla Mobile IP. The 
care-of route is an ordered list of IP addresses that 
a CN will use to source route its packets to the MNN 

IS on the shortest path, thereby achieving route opti- 
misation. 

(Ill) Receiving of extended BU messages by the 
CNs. In response to the received BU messages, 
20 source route packets addressed to MNN through 
the route derived from the care-of route address in 
order to achieve route optimisation. 

(A) Mobile Router Advertising its mobility in the 
25 Mobile Networlc: 

[0064] In order to realize route optimisation for MNNs 
in the case of a single Mobile Network, as well as multi- 
layered aggregated Mobile Networi<s (nested mobility), 

30 the inventive concepts described herein propose to 
make MNNs aware of the mobility of the Mobile Net- 
works (or Mobile Routers) that they are attached to. This 
Is In direct contrast to the approach proposed In [3] 
where a Mobile Router's mobility Is hidden to its respec- 

35 tive MNNs. 

[0065] In order to announce it has moved to a new 
point of attachment, a Mobile Router (e.g. MR1) will 
send a 'Care-of Route Advertisement' message into the 
Mobile Network it serves addressed to all the nodes be- 

40 hind it (i.e. any LFNs, LMNs, VMNs). This message con- 
tains the Care-of address of the MR1 itself, as well as 
the care-of addresses of all the Mobile Routers above 
MR1 in the hierarchy of aggregated Mobile Networks, 
in the case of nested network mobility. This list of above 

45 mobile routers' care-of addresses is preferably ordered 
and constructed dynamically through all the Care-of 
Route Advertisement sent at each level of the hierarchy 
of aggregated Mobile Networks. 
[0066] Referring now to FIG. 6, a network topology 

50 600 for advertising such a mobile router's mobility within 
mobile networks, is illustrated, in accordance with the 
preferred embodiment of the present invention. In par- 
ticular, the topology shown in FIG. 6, illustrates the sup- 
porting nested mobility, in accordance with the pretended 

55 embodiment of the present invention. A skilled artisan 
would recognise that the number of elements shown in 
the network of FIG. 6 are limited for clarity purposes on- 
ly. 
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[0067] The network topology shown In FIG. 6 Illus- 
trates a second Mobile Network (MR2) visiting a first Mo- 
bile Network (MR1 ) that is attached to a visited network. 
The first Mobile Network includes a fixed router (LFR1 ) 
that serves its own link. 

[0068] Since MR1 650 is visiting a foreign network 
110, it has acquired a Care-of Address {MR1_CoA} 652. 
The foreign network 11 0 is fixed, so there is no Care-of 
Route Advertisements forwarded in the link between the 
visited link 110 and MR1 650. In accordance with the 
prefen-ed embodiment of the prBsent invention, MR1 
650 constructs its own Care-of Route Advertisement 
message and includes its own Care-of Address 652 in 
the advertisement message. 

[0069] This message is multicasted to all nodes within 
(below) its own link (MR1 Link 155) through its ingress 
interface. All nodes on the link will therefore receive this 
advertisement message. When receiving such a mes- 
sage, Routers (LFR, LMR, VMR) are expected to extract 
the ordered list of Care-of addresses 652 and forward 
this list on to the links that they serve. In this regard, the 
second MR (MR2) 660 forwards the Care-of addresses 
652 to its own link (MR2 link) 230. If this router is a top 
router of a Mobile Network not within its home network 
(I.e. a VMR as in the case of MR2 660), it will append 
its own Care-of address to the list received. MR2 660 
will then include the MR2 Care-of address 662 In the 
generation of a new ordered- list MR2 will then generate 
its own Care-of Route Advertisement message to be 
multicasted on its own link (MR2 link) 230, through its 
ingress interface. As a consequence, MR1_CoR is ad- 
vertised in the first Mobile Network (including MR1 link 
155 and LFR1 link 670) whilst the ordered-list 
{MR1_CoR 652, MR2_CoR 662} is advertised in the 
second Mobile Network 230. 

[0070] The process of informing CN2 655 of the opti- 
mum route to LFN2 665 via the MR2 care-of-address 
662, using an extended BU message, is described later, 
in this manner, the full route for the data packet can be 
determined by improved extraction, utilisation and ad- 
vertisement of address data throughout the networks. 
[0071 ] The process shown In FIG. 6 illustrates a prac- 
tical scenario, where many nested levels may exist. 
Hence, a skilled artisan would appreciate that the afore- 
mentioned process may be easily generalised to an ex- 
ample of nested mobility involving n successive levels 

(n mobile routers MR^ MR^ and n conrespondlng 

home agents HA^, HA^) . 

[0072] Referring now to FIG. 7, FIG. 8 and FIG. 9, var- 
ious flowcharts 700, 800, 900 are illustrated for any rout- 
er In a mobile network, such as MR VMR LFR and LMR, 
to construct and send a list of care-of addresses to be 
included in a Care-of Route advertisement (CoR_Advt) 
message, in accordance with the prefen-ed embodiment 
of the present invention. Also, these processes are valid 
only for MNN that are routers (e.g. LFR, MRs). 
[0073] Basically, a router in a Mobile Network will 
send a CoR.Advt message in response to one of three 


events: 
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(i) Reception of a CoR_Advt on its egress interface 
that modifies its own CoR, as described in FIG. 7; 

(ii) Periodic sending of a CoR_Advt, as described 
In FIG. 8; and 

(iii) Reception of a Care-of route solicitation 
(CoR_Sol) message on an ingress ifc, as described 
in FIG. 9. 


[0074] In FIG. 7, the process starts at step 7 1 0. A new 
CoR_Advt message is received on its egress interface, 
as shown In step 720, and the list of care-of addresses 
extracted, as described further in process A of FIG. 11 , 

15 If the respective MNN's Care-of Route (MNN_CoR) has 
not been changed in step 740, the process ends in step 
780. However, if the respective MNN^CoR address has 
been changed In step 740, the router builds a new 
CoR^Advt message and Includes (appends) in it the 

20 new MNN_CoR, as shown in step 750. The new 
CoR_Advt message is then sent to all nodes through all 
ingress interfaces of the respective MNN, as in step 760. 
[0075] In FIG. 8, a flowchart illustrates the preferred 
operation If a periodic CoR_Advt message timer has ex- 

25 pired in step 820. In this case, the router builds a new 
CoR_Advt message and includes (appends) in it to the 
MNN_CoR, as shown in step 850. The new CoR_Advt 
message is then sent to all nodes through all ingress 
Interfaces of the respective MNN, as in step 860. The 

30 CoR_Advt message timer is then re-started in step 870 . 
[0076] A router In a mobile network (MR, LFR, LMR, 
VM R) will start periodic transmission of CoR_Advt mes- 
sages only when its CoR becomes non-null (i.e. con- 
tains at least one address). It is envisaged that the router 

35 will terminate this periodic emission when its CoR be- 
comes null/empty. For example, a MR will start the pe- 
riodic emission when it (or a top MR) is moving out of 
its home networic and terminate the periodic transmis- 
sion when it (or the top MR) is returns to its home net- 

40 work. 

[0077] In FIG. 9, a flowchart Illustrates the prefen-ed 
process upon reception of a Care-of route solicitation 
{CoR_Sol) message on an Ingress ifc, as shown in step 
920. In this case, the router builds a new CoR_Advt 

45 message and includes (appends) In It MNN_CoR, as 
shown In step 950, when the (CoR_Sol) message is re- 
ceived on an ingress interface ifc J. Two possible ap- 
proaches are envisaged for the sending of a CoA_Advt 
operation in step 960. A first approach is to send the 

so CoA_Advt message to the source address of the care- 
of Route Solicitation message (CoR_Sol) through IfcJ. 
Alternatively, the CoA_Advt message may be sent to all 
nodes on the links through the ifcj. Note that when a 
mobile router (MR) changes its location, it should send 

55 a CoR_Sol message, in order to receive a CoR_Advt 
message In return. The MR is then able to compute its 
new Care-of Route (CoR). This CoR will be made of the 
ordered list of addresses received in the CoR_Advt 
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message (if not empty) to which MR's new Care-of ad- 
dress is appended. Since this new CoR is not empty, 
the tJ{R will then start periodic sending of its own 
CoR_Advt messages. 

[0078] Several approaches are envisaged for the Im- 
plementation of Care-of Route Solicitation and Care-of 
Route Advertisement messages. First, the messages 
may be Implemented as an Internet Control Message 
Protocol for IPv6, IETF RFC 1885 (ICMPvS) extension, 
or as any new protocol on top of lP(v4 or v6), such as 
User Datagram Protocol, IETF RFC 768 (UDP), Trans- 
mission Control Protocol, IETF RFC 793 (TCP), etc. 
[0079] Secondly, a Care-of Route Advertisement 
message may be sent to the IPv6 all-node link-local mul- 
ticast address. In this case, the message will be sent 
only on the local link. A preferred manner would be to 
send the Care-of Route Advertisement to the IPv6 all- 
node site-local multicast address, where the site is the 
whole Mobile Network served by this MR. This would 
help reduce operation on intemnediate routers (LFR, 
LMR at home) in the Mobile Network since the Care-of 
Route Advertisement would then be forwarded trans- 
parently to all the links of the Mobile network. In this 
manner, there is no need for this Intermediate router 
(LFR, LMR at home) to extract and copy the CoR list. 
[0080] A preferred implementation of these messag- 
es would be to define them as extensions of ICMPv6 
Router Solicitation and ICMPv6 Router Advertisement 
messages. A Care-of Route Advertisement message 
would be an lCMPv6 Router Advertisement message 
(RA) including a new "Care-of Route Advertisement" op- 
tion. A Care-of Route Solicitation message would be an 
ICMPv6 Router Solicitation message (RS) including a 
new "Care-of Route Advertisement" option. The Care- 
of Route Advertisement option would be included in RA 
when a router has to announce its (non-empty)_ CoR 
within the mobile network. The Care-of Route Solicita- 
tion option may be included in RS by a MNN to explicitly 
request for a RA with the Care-of Route Advertisement 
option. If this option were not included in the RA, this 
would mean that the CoR of this router is null/empty. . 
[0081] Referring now to FIG. 24 and FIG. 25, a Care- 
of Route Solicitation message and a Care-of Route Ad- 
vertisement message are illustrated respecth^ely. in ac- 
cordance with the preferred embodiment of the present 
invention. 

[0082] The Care-of Route Solicitation (CoR_Sol) 
message 2400 in FIG. 24 is an lCMPv6 Router Solicita- 
tion message, extended with the new "Care-of Route 
Solicitation" option. It includes a single IP header 2425 
that includes an IP source address 241 0 for a host and 
an IP destination address 2420 Indicating the all-routers 
I P multicast address. The IP header 2425 Is followed by 
a router solicitation message 2430 containing the Care- 
of Route Solicitation (CoR_Sol) option. 
[0083] The Care-of Route Advertisement (CoR_Advt) 
message 2500 in FIG. 25 is an lCMPv6 Router Adver- 
tisement message extended with the new "Care-of 


Route Advertisement" option. It includes a single IP 
header 2525 that includes an IP source address 2510 
for a router's ingress Interface and an IP destination ad- 
dress 2520 indicating a node (or all nodes on the link) 
5 that is to receive the packet. The IP header 2525 is fol- 
lowed by a router advertisement message 2530 contain- 
ing the Care-of Route Advertisement option that in- 
cludes the Care-of Route (i.e. ordered list of addresses) 
as advertised by the router. 

10 

B) MNNs sending extended Binding Updates to their 
respective CNs: 

[0084] Any MNN, including a LFN, a LMN or a VMN, 

15 in a Mobile Network is expected to send so-called ex- 
tended Binding Updates to its CNs in order to achieve 
route optimisation on the path CN MNN. In accord- 
ance with the preferred embodiment of the present in- 
vention, an extended BU message sent by a MNN would 

20 include a "care-of route' instead of a single care-of ad- 
dress, as known in Mobile IP. As described above, the 
care-of route is the ordered-list of IP addresses for the 
CN to derive a source route from, in order to route Its 
packet to the MNN through the shortest path (i.e. route 

25 optimisation). 

[0085] Refenrlng now to FIG. 10, a network topology 
1000 for sending extended BUs to CNs, is illustrated in 
accordance with the preferred embodiment of the 
present invention. For clarity purposes only, the topolo- 

30 gy follows on from that described above with respect to 
FIG. 6. 

[0086] Each MNN in the Mobile Network derives its 
care-of route from the Care-of Route Advertisement 
messages it receives from its upper router. For instance, 

35 LFN1 675 care-of route is a single hop route equal to 
MR1 650's Care-of Address {MR1_CoA} 652. LFN1 675 
then transmits an extended BU message 1010 indicat- 
ing its care-of route to CN1 1030. 
[0087] In contrast, LFN2 665*s care-of route is a two- 

40 hop route equal to {MR1_CoA MR2_CoA}. In this 

context, the LFN2 665 Care-pf Route utilises MR2 CoA 

662 and the upper router from MR2, namely MR1 650*s 
CoA 652. LFN2 665 then transmits an extended BU 
message 1020 Indicating the MR1_CoA 652 and the 

45 MR2 CoA 662 to CN2 655. 

[0088] Referring now to FIG. 1 1 , a preferred algorithm 
for a MNN to generate its own care-of route 
(MNN_CoR), in accordance with embodiments of the 
present invention, is described. The process (process 

50 A) starts at step 1110. When the MNN receives a new 
CoR_Advt message on Its Interface ifcj, in step 1120, 
it detemiines whether It is an egress interface, In step 
1130. If it is not an egress Interface, the CoR_Advt is 
ignored and the process ends in step 11 90. In this case, 

55 the MNN Care-of Route is unchanged. 

[0089] If ifcJ in an egress interface, then the MNN 
extracts a new CoR (new CoR) • ordered list of IP ad- 
dresses - from the CoR__advt In step 1 1 40, and a deter- 
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minatlon Is made as to whether the MNN is at home (i. 
e. ifcj is attached to its home IP subnet) In step 1150. 
If the IWNN is at home, the MNN_CoR Is replaced by the 
new Care-of Route information In step 1180, If there is 
a difference between the routes In step 1 170. If the MNN 
is not at home, the MNN care-of route Is constructed by 
appending the MNN care-of address (obtained in the 
visited network) to the ordered-list of care-of addresses 
received in the care-of route advertisement message, 
in step 1160. 

[0090] Note that a MNN may not maintain such a 
Care-of Route if it does not intend to benefit from route 
optimisation on the path CN^MNN, or on the path 
HA^MNN. However, in the preferred embodiment of 
the present Invention, it is recommended that such 
Care-of Route knowledge be maintained, in order to lev- 
erage the approaches described in [3] and [5]. In this 
manner, It is possible to achieve route optimisation on 
the path HA MN, where the MN is either a host or a 
router, as described later. 

[0091] Note that the approach described in FIG. 1 1 Is 
valid for any MNN, either a router or a host, either fixed 
or mobile. 

[0092] Referring now to FIG. 12 and FIG. 13, flow- 
charts of an MNN sending extended BU messages to 
Its CN{s) (and Home Agent - HA), are illustrated in ac- 
cordance with the preferred embodiments of the present 
invention. The flowcharts are again applicable to any 
MNN, either a host or a router, fixed or mobile. 
[0093] FIG. 12 describes a flowchart 1200 for sending 
extended BU messages to Its CN(s) (and HA) following 
a reception of a CoR_Advt message on its egress inter- 
face, in step 1215. Upon reception of a CoR_Advt mes- 
sage, the MNN perfomns process 'A' described In FIG. 
11, to generate its own CoR, as shown In step 1220. If 
its CoR has not changed in step 1 225, the process ends, 
in step 1265. However, if the CoR has changed in step 
1225, the MNN detennlnes all of Its CNs that need to 
receive an updated CoR message, in step 1 230. In order 
to send an extended BU message containing the updat- 
ed CoR message, in step 1240, the MNN steps through 
each of the CNs, starting with the first CN in step 1235. 
If the CN receiving the extended BU message contain- 
ing the updated CoR message transmission Is not the 
last CN identified by the MNN, in step 1245, the process 
moves to the next CN in step 1 250 until ail CNs have 
received the transmission. 

[0094] A preferred, optional step is for the MNN, which 
Is not at home, to send a message including its new 
Care-of Route (CoR) to its Home Agent (HA), either an 
Extended BU or an Extended Prefix Scope BU (if the 
MNN used [3] to send BU to its HA), as shown in steps 
1255 and 1260. 

[0095] FIG. 13 describes an alternative flowchart 
1300 for sending extended BU messages to its CN(s) 
(or its HA) following periodic sending of extended BUs 
(EBUs) to CNs (and again HA if MNN is a mobile host 
or router). Again, this periodic sending takes place only 
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when the MNN's CoR is non-null following expiration of 
the periodic EBU timer associated to a particular CN (e. 
g. CNi) or MNN's HA, in step 1320. The extended BU 
message containing the updated CoR message is sent 
5 to CNi (or HA) in step 1 330 . The timer function , associ- 
ated to the respective CN (e.g. CNi or HA), is then re- 
started in step 1 340. 

[0096] Note that in relation to FIG. 12 and FIG. 13, a 
CN may be a fixed or mobile host In the Internet as well 
w as another MNN (from the same or different Mobile Net- 
work). 

[0097] Still referring to FIG. 12 and FIG. 13, rf the MNN 
(host or router) is at home (I.e. Is a LFN, a LMN at home), 
the MNN sends an extended Binding Update to all its 

15 CNs (and" not to its HA since it is at home). If the MNN 
(host or router) is in a visited network (i.e. is a VMN), 
the MNN sends an extended Binding Update to all its 
CNs as well as preferably its Home Agent. 
[0098] The MNN may send an extended Binding Up- 

20 date to Its Home Agent, in case it wants to achieve route 
optimisation on the path HA MNN . This approach ex- 
tends the techniques proposed in [3] and [5], by sending 
extended BUs instead of their basic Binding Updates. 
In the case of [3], the Mobile Router (MR) sends a so- 

25 called prefix scope BU message to its HA. In this con- 
text, we define here an extension of this binding update 
message called 'extended prefix-scope binding update', 
which includes the MR Care-of route instead of only MR 
care-of address. This extended prefix-scope binding up- 

30 date may be sent by the MR to its HA to achieve route 
optimisation on the path HA MR. 
[0099] In the case of [5], the Mobile Router (MR) 
sends a basic Mobile IP binding update, in this context, 
we define an extension of this BU message as an 'ex- 

35 tended Binding Update' (as detailed above). This in- 
cludes the MR Care-of Route instead of only MR care- 
of address. This extended binding update may be sent 
by the MR to its HA to achieve route optimisation on the 
path HA MR. 

40 [0100] It is worth mentioning that each MNN that 
sends extended BU messages preferably maintains an 
'extended Binding List', defined as an extension of the 
Mobile IP binding list, where Care-of Addresses are re- 
placed with Care-of Routes. 

45 [0101] Refen^ing nowto FIG. 14 and FIG. 15 Illustrate 
flowcharts of an optimised process for an MNN sending 
an extended BU to its CN(s) (and its HA) for intra-mo- 
bile-networic communication, in accordance with an en- 
hanced embodiment of the present invention. It is en- 

50 visaged that the enhanced process improves networic 
perfomnance by avoiding sending "useless" extended 
BU messages in the case of intra-moblle-networi< com- 
munication. In fact, when two nodes (eitherfixed, ormo- 
bile at home) in the same mobile network (i.e. not sep- 

55 arated by a Mobile Router away from home) are sending 
packets to each other, route optimisation will be realised 
naturally by the routing Infrastructure within the mobile 
network. As such, there is no need for them to exchange 
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extended BU messages between each other. 
[0102] In FIG. 14, as an extension to the flowchart of 
FIG. 12, when the MNN is a host at home (i.e. is a LFH, 
or a LMH at home), the MNN sends an extended Binding 
Update to onty its CNs that are not in the same mobile s 
network, as in step 1 41 0. Also, when the MNN is a router 
at home (i.e. is a LFR, or a LMR at home), the MNN 
sends an extended Binding Update to only its CNs that 
are not in the same mobile network, as in step 141 0. If 
the MNN (host or router) is in a visited network (I.e. is a io 
VMN) in step 1420, the MNN sends an extended Binding 
Update to only CNs that are not in this visited mobile 
network. In step 1240. For CNs that are in the visited 
mobile network, the MNN may send an extended Bind- 
ing Update, or preferably send a modified extended 
Binding Update where only one address is specified in 
the care-of route, I.e. only the MNN's own care-of ad- 
dress, in step 1430. 

[0103] The mobile MNN (host or router) preferably 
sends also a Binding Update to Its Home Agent in step 20 
1 260 and 1 450. Two cases are considered below, in this 
regard. When the MNN has moved out of its home mo- 
bile network, the MNN preferably sends an extended 
Binding Update to its HA. When the MNN is in a foreign 
IP-subnet within its home mobile network, the MNN may 25 
send an extended Binding Update. Alternatively, the 
MNN may send a modified extended Binding Update 
where only one address is specified in the care-of route, 
i.e. its own Care-of Address. 

[0104] Again, it is envisaged that the MNN may send 30 
an extended BU message to its Home Agent, in the case 
where the MNN wants to achieve route optimisation on 
the path HA -> MNN, by sending extended BUs in the 
operation of [3] or extended prefix scope BUs in the op- 
eration of [5] as described above. 35 
[01 05] A similar enhancement to FIG. 1 3 is described 
In FIG. 15, with the transmission of extended BU mes- 
sages containing only the MNN_CoAto respective CNs 
that are operating in the same Mobile Network as the 
MNN, as shown in steps 1510, 1520, 1530. 40 
[0106] Referring now to FIG. 26 and FIG. 27 an ex- , 
tended BU message sent from a LFN and a VMN are 
illustrated respectively, In accordance with the preferred 
embodiment of the present invention. 
[0107] The extended BU message sent from a LFN 45 
message 2600 in FIG. 26 includes a single IP header 
2625 that includes as IP source address 2610 the LFN 
and as IP destination address 2620 for the CN's ad- 
dress. The IP header 2625 is followed by a Mobile IPv6 
BU message 2630 containing the Care-of Route mobll- so 
Ity option incorporating the LFN's Care-of Route. 
[0108] The extended BU message sent from a VMN 
message 2700 In FIG. 27 includes a single IP header 
2725 that includes an IP source address 2710 of the 
VMN care-of address and an IP destination address 55 
2720 for the CN. The IP header 2725 is followed by a 
Mobile IPv6 BU message 2730 containing the Care-of 
Route mobility option incorporating the VMN's Care-of 


Route. 

[0109] Refen-ingnowtoFIG. 16 a flowchart 1600 of a 
dynamic discovery method of a mobile network prefix 
for any MNN in a mobile network is illustrated, in accord- 
ance with the enhanced embodiment of the present in- 
vention described above. In this context, a node such 
as a MNN is able to know whether a second node, say 
its CN, is in the same current Mobile Networic as itself 
when sending an EBU to say the CN, as described 
above. 

[0110] The process (process B) starts at step 1610. 
When the MNN receives a new Mobile Network Prefix 
Advertisement message (Mobile_Network_Prefix_Ad- 
vt) on its interface ifcj, in step 1620, it detemriines 
whether it is an egress interface, in step 1 630. If it is not 
an egress interface, the Mobile_Network_Prefix_Advt is 
ignored and the process ends in step 1 670. In this case, 
the MNN's mobile network prefix (MNN_Mobile_ 
Netowrk_Prefix) is unchanged. If IfcJ in an egress in- 
terface, then the MNN extracts a new Mobile Network 
Prefix (new_Mobile_Network_Prefix) and its prefix 
length (new_MoblIe_Network_Prefix Length) from the 
Mobile_Network^Pref ix_Advt in step 1 640, and a deter- 
mination is made as to whether the MNN's home ad- 
dress in ifcJ matches New_Mobile_Network_Prefix on 
the first New_Mobile_Network_Prefix_Length bits, In 
step 1650. If it matches, the MNN_Mobile_ 
Network_Pref!x and MNN_Mobile_Netowrk_Prefix_ 
Length are replaced by the new Information in step 
1 650, and the process ends In step 1 670. If there Is not 
a match, the process ends directly in step 1670. 
[0111] Note that the approach described in FIG. 1 6 is 
valid for any MNN, either a router or a host, either fixed 
or mobile. 

[0112] Referring now to FIG. 17, FIG. 18 and FIG. 19, 
various flowcharts 1700, 1800, 1900 are illustrated for 
a fixed router in a mobile networic (i.e. LFR) to construct 
and send its own Mobile Network Prefix Advertisement 
(Mobile_Networi<_Prefix__Advt) messages, in accord- 
ance with the enhanced embodiment of the present In- 
vention. 

[0113] Basically, afixed router in a Mobile Network will 
send a Mobile_Network_Prefix_Advt message in re- 
sponse to one of three events: 

(i) Reception of a Mobile_Network_Prefix_Advt on 
an egress interface that modifies its own 
MNN_Mobile_Networi<_Preflx, as described in FIG. 
17; 

(II) Periodic sending of a Moblle_Networic_Prefl)e. 
Advt, as described In FIG. 18; and 

(iii) Reception of a Mobile Network Prefix Solicita- 
tion message (Mobile_Network_Prefix_Sol) on an 
ingress ifc, as described In FIG. 19. 

[0114] In FIG. 17, the process starts at step 1705. A 
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new Mobi!e_Network_Prefix_Advt message is received 
on an egress interface, as shown in step 1710, and the 
new Mobile Networic Prefix (New_Mobile_ 
Network_Prefix) and its length are extracted, as de- 
scribed further in process B of FIG. 1 6. If the respective 
MNN_Mobile_Network_Prefix and MNN_Mobile_ 
Networi<_Prefix_Length have not been changed in step 
1720, the process ends in step 1735. However, if the 
respective MNN_l\/lobile_Network_Prefix and/or 
MNN_Moblle_Network_Prefix_Length have been 
changed in step 1720, the router builds a new 
Mobile_Network_Prefix_Advt message and includes 
(appends) in it the new MNN_Mobile_Network_Prefix 
and MNN_Mobile_Network_Prefix_Length, as shown in 
step 1725. The new Mobile_Network_Prefix_Advt mes- 
sage is then sent to all nodes through all ingress inter- 
faces of the respective MNN. as In step 1 730. The flow- 
chart described in FIG. 1 7 only applies to a fixed router 
in a mobile network. 

[01 15] In FIG. 1 8, a flowchart illustrates the preferred 
operation if a periodic Mobile_Network_Prefix_Advt 
message timer has expired in step 1810. In this case, 
the router builds a new Mobile_Network_Prefix_Advt 
message and includes (appends) in it the 
MNN_Mobile_Network_Prefix and MNN_Mobile_ 
Networi<_Prefix_Length, as shown in step 1815. The 
new Mobil e_Network_Prefix_Advt message is then sent 
to all nodes through all ingress Interfaces of the respec- 
tive MNN (fixed router), as in step 1820. The 
Mobile_Network_Prefix_Advt message timer is then re- 
started in step 1 825. The flowchart of FIG. 1 8 applies to 
any router In a mobile network (IVIR, LMR, LFR, VMR). 
[0116] A router in a mobile networi<(l\/IR, LFR, LMR, 
VMR) will start periodic transmission of Mobile_ 
Networic_Prefix_Advt messages only when its CoR be- 
comes non-null (i.e. contains at least one address). It is 
envisaged that the router will tenninate this periodic 
emission when its CoR becomes null/empty. For exam- 
ple, a MR will start the periodic emission when it (or a 
top MR) is moving out of its home networic and terminate 
the periodic transmission when it (or the top MR) has 
returned to its home networi<. 

[0117] In FIG. 19, a flowchart Illustrates the preferred 
process upon reception of a Mobile Network Prefix So- 
licitation message (Mobile_Network_Prefix_Sol) on an 
ingress ifc, as shown in step 1910. In this case, the rout- 
er builds a new Mobile_Network_Prefix_Advt message 
and includes (appends) in it MNN_Moblle_Network_ 
Prefix and MNN_Mobile_Network_Prefix_Length, as 
shown In step 1920, when the (Mobite_Network_ 
Prefix__Sol) message Is received on an Ingress interface 
ifc J. Two possible approaches are envisaged for the 
sending of a Mobile_Networtc_Prefix_Advt operation in 
step 1925. A first approach is to send the message to 
the source address of the Mobile Network Prefix Solic- 
itation message (Moblle_Network_Prefix_SoO through 
ifc J. 

Alternatively, the Mobile Networt< Prefix Advertisement 


message may be sent to all nodes on the links through 
the ifc J. The flowchart of FIG. 19 applies to any router 
in a mobile network (MR, LMR, LFR, VMR). 
[0118] Note that when a mobile router (MR) changes 
5 its location (and thus get a non-null CoR), it should send 
a MobiIe_Networi<_Prefix_Advt on its ingress Interfac- 
es. 

[0119] This mobile router may know this prefix from 
its internal configuration. On the other hand, fixed rout- 

10 ers in the mobile network (i.e. LFR) may not a-priori 
know the mobile network prefix they belong to and can 
discovery it dynamically thanks to the process described 
in FIG. 17. Such fixed routers may of course send a 
Mobile_Network_Prefix_SoI message, in order to re- 

15 ceive a Mobile_Network_Prefix_Advt message in re- 
turn. 

[0120] Several approaches are envisaged for the im- 
plementation of Mobile Networic Prefix Solicitation and 
Mobile Network Prefix Advertisement messages. First, 
20 the messages may be implemented as ICMPvS exten- 
sion, or as any new protocol on top of IP, U DP, TCP, etc. 
ICMP, UDP and TCP are protocols that build upon IP{v4 
or v6): 

25 - ICMPv6: Internet Control Message Protocol for 
IPv6, IETF RFC 1885 

- UDP: User Datagram Protocol, IETF RFC 768 

- TCP: Transmission Control Protocol, I ETF RFC 793 

30 [0121] Secondly, a Network Prefix Advertisement 
message may be sent to the IPv6 all-node link-local mul- 
ticast address. In this case, the message will be sent 
only on the local link. A prefen'ed manner would be to 
send the Care-of Route Advertisement to the IPv6 all- 

35 node site-local multicast address, where the site is the 
whole Mobile Network served by this MR. This would 
help reduce operation on intemriedlate routers (I.e. LFR) 
in the Mobile Network since this message would then 
be foHAfarded transparently to all the links of the Mobile 

40 network. In this manner, there is no need for this inter- 
mediate router (i.e. LFR) to extract and copy the Mobile 
Network Prefix, 

[0122] A preferred implementation of these messag- 
es would be to define them as extensions of ICMPvS 

45 Router Solicitation and ICMPvS Router Advertisement 
messages. A Mobile Networic Prefix Advertisement 
message would be an ICMPvS Router Advertisement 
message (RA) including a new "Mobile Networic Prefix 
Advertisement" option. A Mobile Network Prefix Solicl- 

50 tation message would be an ICMPv6 Router Solicitation 
message (RS) including a new "Mobile Networic Prefix 
AcJvertisement" option. The Mobile Network Prefix Ad- 
vertisement option would be included In RA when a rout- 
er has to announce the mobile network prefix within the 

55 mobile network. The Mobile Networic Prefix Solicitation 
option may be included in RS by a MNN to explicitly re- 
quest for a RA with the Mobile Network Prefix Advertise- 
ment option. 
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[01 23] Referring now to FIG. 22 and FIG. 23, a mobile 
network prefix solicitation message and a mobile net- 
worl< prefix advertisement message are illustrated re- 
spectively, In accordance with the preferred embodi- 
ment of the present invention. 
[0124] The mobile network prefix solicitation mes- 
sage 2200 in FIG. 22 is an ICMPv6 Router Solicitation 
extended with the new Mobile Network Prefix Solicita- 
tion option. It includes a single IP header 2225 that in- 
cludes an IP source address 221 0 for a host and an iP 
destination address 2220 Indicating the all-routers IP 
multicast address. The IP header 2225 is followed by 
the router solicitation message 2230 containing the mo- 
bile network prefix solteitation option proposed in this 
document. 

[0125] The mobile network prefix advertisement mes- 
sage 2300 in FIG. 23 Is an ICMPvS Router Advertise- 
ment message extended with the new mobile network 
prefix advertisement option. It includes a single IP head- 
er 2325 that includes an IP source address 2310 for a 
router's ingress interface and an IP destination address 
2320 indicating a node (or all nodes on the link) that is 
to receive the packet. The IP header 2325 is followed 
by the router advertisement message 2330 containing 
the mobile network prefix advertisement option that in- 
cludes the mobile network prefix and the mobile network 
prefix length advertised by the router. 

C) Correspondent Nodes and Home Agent receiving 
extended Binding Update: 

[0126] Referring now to FIG. 20, a flowchart 2000 il- 
lustrates a process for a first node to send a data packet 
to a second node based on the parsing of its Extended 
Binding Cache (EBC), in accordance with the preferred 
embodiments of the present invention. A first node, for 
example a CN or HA, receives an indication that a data 
packet is to be sent to a second node, for example a 
MNN, as shown In step 2020. The CN searches for the 
MNN's address within an extended binding cache (EBC) 
that stores the Care-of Source routes derived from care- . 
of route Infomiation received In extended BUs, as In step 
2030. 

[0127] If the MNN's address Is found. In step 2040, 
the CN (or HA) is able to source route the packet, 
through the Care-of Source route found in the EBC, to 
the MNN's address achieving route optimisation, as in 
step 2050. Otherwise, the CN sends the data packet to 
the MNN directly to MNN's Home Address using the 
known technique, as shown in step 2060. 
[01 28] Referring now to FIG. 21 , prefen^ed examples 
of data packet fomnats, sent by a first node, say a CN, 
to a second node, say a MNN, are Illustrated in accord- 
ance with the preferred embodiments of the present in- 
vention. 

[01 29] A first f onmat of a data packet 21 00 includes a 
single IP header 2110 that includes an IP source ad- 
dress 21 12 and an IP destination address 2114 equal to 


the first IP address in CN's Care-of Source Route to 
MNN . The single I P header 21 1 0 is followed by a routing 
header 2 1 20 containing the (m-1 ) other addresses (from 
CN's Care-of Source route to MNN) in the route to the 

5 second node. 

The data payload 21 30 follows the routing header. 
[0130] A second fomnat of a data packet 2150 in- 
cludes 'm' consecutive IP headers each including re- 
spective IP source addresses 2112, 2152, 2162, 2172 

10 and respective IP destination addresses 2114, 2154, 
2164, 2174. The 'm' consecutive IP headers do not 
therefore need a separate routing header, so the data 
payload 2180 follows the IP headers. Each of the con- 
secutive IP headers has its IP destination address set 

15 equal to one of the IPaddressesof CN's Care-of Source 
route to MNN. The fist header contains the first address 
of the Care-of Source Route (CoSR), the second header 
contains the second address, and so on to the last head- 
er. The final IP header 21 72, 2174, together with the da- 

20 ta payload 21 80, constitutes the original packet 21 90 to 
be sent from the first node to the second node. 
[0131] Each node (CN, MNN, HA) that is expected to 
receive extended Binding Updates is to maintain an ex- 
tended Binding Cache (EBC). The EBC is herein de- 

25 fined as an extension of Mobile I P binding cache where 
care-of addresses are replaced with 'care-of source 
routes" (CoSR) derived from the care-of routes (CoR) 
received in the extended Binding Updates, it is worth 
mentioning that the care-of source route listed in the ex- 

30 tended binding cache may be slightly different (i.e. 
shorter) from the care-of route received in the extended 
Binding Update. 

[0132] Refening now to FIG. 28 an extended binding 
cache 2800 is illustrated in accordance with the pre- 
ss ferred embodiment of the present Invention. 

[0133] The extended binding cache 2800 includes a 
list of entries 2810, 2840, 2870, each one specific to a 
home address of a MNN. The extended binding cache 
entry 2810 includes, for example, a first home address 
40 2815, with a link 2818 to a first Care-of Source route 
. . 2820, if one has. been determined. The first Care-of 
Source route 2820 Includes respective linked Care-of 
Source route addresses 2825, 2830, and 2835 to Iden- 
tify the route to the first home address. The first entry 
45 281 0 is linked 2837 to a second entry 2840 having a link 
2848 from a second home address 2845 to a second 
Care-of Source route 2850, if one has been detemnined. 
The second Care-of Source route 2850 includes respec- 
tive linked Care-of Source route addresses 2855, 2860, 
50 and 2865 to identify the route to the second home ad- 
dress. A similar an^angement and link 2867 is performed 
to a third entry 2870, and so on. 
[0134] It is witliln the contemplation of the invention 
that the extended BU may also include entries for a mo- 
55 bile router (MR) prefix and prefix length. This is partic- 
ularly useful when an MR sends an extended prefix- 
scope BU to its HA or CNs, as an extension to [3], where 
the CoR replaces the CoA in the prefix-scope binding 
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update. In this case, the Home Address field is replaced 
with a "prefix and prefix length" field in the EBC of the 
respective HA or CNs. 

[01 35] Referring now to FIG. 29, the construction of a 
care-of-source route 2900 from a received extended BU 
is illustrated, in accordance with the preferred embodi- 
ment of the present invention . A first node Care-of Route 
(N1_CoR) contains an ordered list of Care-of Route ad- 
dresses (N1_.CoR[1l, N1„CoR[2], ...) 2910. When the 
first node N1 receives an extended BU message from a 
second node N2 containing N2's Care-of Route 
(N2_CoR), the first node compares the two ordered list 
of Care-of Route addresses, to determine when there is 
a difference between them 2940. The address from 
N2_CoR that was detemnined as being different, and all 
subsequent addresses from N2_CoR, is then used to 
generate a new Care-of Source Route 2930 for data 
packet transmissions from N1 to N2. This process is fur- 
ther described with respect to the flowchart of FIG. 30. 
[0136] Referring now to FIG. 30, a flowchart 3000 a 
process of determining a Care-of Source Route to be 
included in an extended Binding Cache is illustrated, in 
accordance with preferred embodiments of the present 
invention. A first node (N1) receives an extended Bind- 
ing Update from a second node {N2) and needs to de- 
termine the care-of source route to be included In the 
extended Binding Cache for this entry (N2). 
[0137] The process starts at step 3002. When a first 
node (N1 , which may be itself a MNN at home or in a 
foreign network, or any host in the topology) receives 
an EBU containing a new Care-of Route for a second 
node (N2}, in step 3004, N1 detennines whether this N2 
Care-of Route (received in the EBU) is empty in step 
3006. 

[01 38] If the new Care-of Route for N2 received in the 
EBU is empty, in step 3006, N1 searches through its ex- 
tended Binding Cache to check whether there is an entry 
(i.e. a care-of source route) for this second node in the 
EBC, as shown in step 3008. If no entry exists in the 
EBC, the process ends in step 3046. In this case, no 
entry in NVs extended binding cache is needed for N2. 
When addressing packet to N2's home address, the da- 
ta packet from N1 will be directly on the shortest path 
(route optimisation is achieved without needing source 
routing). However, if an entry exists in the EBC in step 
3008, the second node entry is removed (I.e. 

N1 CoSR(to N2)) in step 3010, before the process 

ends at step 3046. 

[0139] If the new N2 Care-of Route received in the 
EBU is not empty, In step 3006, a determination is made 
in step 301 2 as to whether a Care-of Route entry is avail- 
able for the first node. If a Care-of Route is not available 
for the first node in step 3012, a first node (N1) Care-of 
Source Route to the second node (N2) is generated to 

be equal to the second node Care-of Route (N1 ^CoSR 

(to N2):= N2_CoR), as shown in step 3014. N1 then 
searches through its extended Binding Cache to check 
whether there is an entry (i.e. a care-of source route) for 
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this second node In the EBC, as shown In step 3016. If 
no entry exists in the EBC, an entry for N2 is added to 
the EBC (N1_CoSR (to N2)), in step 3020 and the proc- 
ess ends in step 3046. If an entry exists in the EBC in 
5 step 3016, the second node entry is updated (i.e. 
N1_CoSR(to N2)) In step 301 8, before the process ends 
at step 3046. 

[0140] If the first node has its own Care-of Route in 
step 301 2, all addresses in the two nodes care-of routes 

10 (N 1 and N2) are searched, starting with setting a counter 
(1=0) in step 3022. N1 compares, one by one, the IP ad- 
dresses in its own care-of route (N1_CoR) with the IP 
addresses listed in the care-of route of the extended 
Binding Update received from node N2, in step 3024. 

15 [0141] It starts with the first addresses N1_CoR(1) 
and N2_CoR(1 ), and continues thereafter. If a match for 
a particular address of the first and second nodes care- 
of routes is found, in step 3026, a detemriination is made 
as to whether the second node Care-of Route address 

20 is the last address, in step 3028. If it is the last address, 
the complete Care-of Route of N2 has been searched, 
in step 3030, and the process moves to step 3008 as 
described above. If the second node Care-of Route ad- 
dress is not the last address, in step 3028, a determina- 

25 tion is made as to whether the first node Care-of Route 
address Is the last address for the first node, in step 
3032. If the first node Care-of Route address is not the 
last address, in step 3032, the counter is incremented 
in step 3034, and the next addresses searched in step 

30 3024. If the first node Care-of Route address is the last 
address, In step 3028, or no match was found in step 
3026, the searching process stops in step 3036 and the 
care-of source route to N2, from N1 , is set in 3038. 
[0142] In 3038, the care-of source route to N2, from 

35 N1 , is set to be equal to ordered list of addresses part 
of N2's care-of route starting from the i^ address to the 
last one. This i^ address being the one where the loop 
in N2's care-of route addresses stopped in step 3036. 
That is: N1_CoSR(to N2) = {N2_CoR(i) ^ N2_C0R(i+1) 

40 ... N2_COR(n-1) N2_CoR(n)}. N1 then search- 
es through its extended Binding Cache to check whether 
there is an entry (I.e. a care-of source route) for this sec- 
ond node In the EBC, as shown in step 3040. 
[01 43] If no entry exists in the EBC, an entry for N2 is 

45 added to the EBC (N1_CoSR (to N2)). in step 3042 and 
the process ends in step 3046. If an entry exists In the 
EBC in step 3040, the second node entry is updated (i. 
e. N1_CoSR(to N2)) in Nl's EBC in step 3044, before 
the process ends at step 3046. 

50 [0144] If N1 has no care-of route (NR_CoR is empty 
or does not exist) in step 3012, then the care-of source 
route to N2, from N1 , is set to be equal to N2's care-of 
route in step 3014. That is: N1_CoSR(to N2) = N2_CoR. 
N1 then searches through its extended Binding Cache 

55 to check whether there is an entry (i .e. a care-of sou rce 
route) for this second node in the EBC, as shown in step 
3016. If no entry exists in the EBC, an entry for N2 is 
added to the EBC (NI^CoSR (to N2)), in step 3020 and 
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the process ends in step 3046. If an entry exists in tlie 
EBC In step 3016, the second node entry is updated (I. 
e. N1_CoSR (to N2)) In Nl's EBC in step 3018, before 
the process ends at step 3046. 
[01 45] N1 should then source route the packet via the 
care-of source route to N2 In order to achieve route op- 
timisation, as described with reference to FIG. 21 and 
FIG. 22. This can be implemented in several ways, as 
described previously. A first way is to use the IPv6 Rout- 
ing Header. In this case, the first address In the care-of 
source route is set as the destination address in the I Pv6 
header and the remaining addresses of the care-of 
source route (CoSR) are set in the Routing Header in 
the same order. A second way is for the first node to 
build 'n' level of encapsulation of the data packet to be 
sent, where 'n* Is the number of addresses in the care- 
of source route. The encapsulation #k will have the ad- 
dress #k, of the ordered-llst of addresses in the care-of 
source route, as the destination address. 
[0146] Furthermore, the various steps described 
above need not necessarily be performed in the order 
they have been described. A skilled artisan would rec- 
ognise that an altemative order may be used, where 
benefit can still be gained In the route optimisation proc- 
ess. 

[0147] It is to be appreciated that the arrangement 
and specific details of interfaces, address types, routers 
etc. in the above embodiments are merely examples, 
and the invention is not limited to these examples. The 
invention should be viewed as capable of being applied 
to other aspects of the Internet or other types of data 
networks or protocols and subnets thereof. Further- 
more, the invention may also be applied to networks oth- 
er than the Internet, when such networks have subnets 
and access networks corresponding to those described 
above for the case of the Internet. 
[0148] The Invention, or at least embodiments there- 
of, tend to provide the following advantages, singly or In 
combination: 

(i) A data packet may be transmitted much more ef- 
ficiently, using this improved route optimisation 
technique. 

(11) Improved privacy of data packet transmissions, 
as each node In the topology Is responsible in send- 
ing their own Binding Updates to their CNs and 
Home Agent. Hence, each node is able to decide 
whether it wishes to disclose its cument location by 
sending a Binding Update in order to perfomi route 
optimisation. This is a clear advantage over [3] 
where privacy Is not allowed. 

(ill) The security solutions defined by the IETF, to 
provide "address ownership" authorisation (e.g. 
Retum Route-ability), are still applicable In the con- 
text of the present invention. This Is again a clear 
advantage over [3], which requires a new security 


mechanism to be Introduced. 

(iv) A secured exchange of new messages (e.g. 
"Care-of Route Advertisement") introduced in the 

5 present invention can be very easily realised, either 
through shared secret (in the case of nodes belong- 
ing to the same organisation) or thro ugh a new I ETF 
protocol such as PANA in the case of a IVIobile Node 
(host or router) visiting a foreign network. 

10 

(v) A solution for efficient data routing in IPv6, IPv4 

or similar data network protocol has been achieved, 
particularly for systems supporting nested network 
mobility. 

15 

[0149] Whilst the specific and preferred implementa- 
tions of the embodiments of the present invention are 
described above, it is clear that one skilled In the art 
could readily apply variations and modifications of such 

20 inventive concepts. 

[0150] Thus, a mechanism, apparatus and associat- 
ed methods to support route optimisation in Network 
mobility, especially in the case of IPv6, have been de- 
scribed, whereby the disadvantages associated with 

25 known mechanisms, apparatus and associated meth- 
ods have been substantially alleviated. In particular, a 
mechanism, apparatus and associated methods to sup- 
port route optimisation in the case of nested mobility, 
have been described. 

30 

Claims 

1 . A method of transmitting (2000) a data packet on a 
35 communication path from a first communication 

node to a second communication node in a mobile 
network, the method characterised by the steps of: 

receiving a route message from said second 
40 communication node, wherein said route mes- 

sage Includes a list of intermediary addresses 
between said first communication node and 
said second communication node; 
generating (301 4, 3038) a preferred communi- 
45 cation path in response to said list of interme- 

diary addresses; and 

transmitting (2050) said at least one data pack- 
et from said first communication node to said 
second communk^tion node via said prefenred 
so communication path. 

2. The method of transmitting a data packet according 
to Claim 1, wherein said data communication net- 
work supports nested network mobility operation 

55 and said step of transmitting includes the step of: 

routing said at least one data packet via a plu- 
rality of mobile routers identified by said inter- 
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mediary addresses in said nested mobility net- 
work. 

3. The method of transmitting a data packet according 
to Claim 1 or Claim 2, wherein said data communi- 
cation network operates in accordance with an IPv6 
and/or IPv4 specification. 

4. The method of transmitting a data packet according 
to any preceding Claim, wherein said first commu- 
nication node is a correspondent node of the said 
second communication node and/or said second 
communication node is a mobile network node. 

5. The method of transmitting a data packet according 
to any preceding Claim, the method further charac- 
terised by the step of: 

sending an advertising message, by a plurality 
of communication nodes in the mobile network, 
that includes route information related to com- 
munication nodes attached to said second 
communication node, so that a communication 
path to an intended recipient can be deter- 
mined. 

6. The method of transmitting a data packet according 
to any preceding Claim, wherein said list of interme- 
diary addresses includes addresses of one or more 
mobile routers above the second communication 
node in a route hierarchy for delivering said data 
packet to an intended recipient. 

7. The method of transmitting a data packet according 
to Claim 5 or Claim 6, the method further charac- 
terised by the step of: 

requesting transmission of one or more adver- 
tisement messages, containing route infomna- 
tion of one or more IP addresses, from adjacent 
communication nodes when said second com- 
munication node moves to a new location within 
the mobile network. 

8. The method of transmitting a data packet according 
to any of preceding Claims 5 to 7, the method further 
characterised by the steps of: 

extracting intermediary route messages from 
said list of intermediary routes in said advertis- 
ing message at a communication node; and 
transmitting said route messages to communi- 
cation nodes that the extracting communication 
node serves. 

9. The method of transmitting a data packet according 
to Claim 8, the method further characterised by the 

step of: 


appending its own route message to said list of 
intemiediary routes in said advertising mes- 
sage at said communication node. 

5 1 0. The method of transmitting a data packet according 
to any of preceding Claims 5 to 9, the method further 
characterised by the step of: 

sending periodically said route advertisement 
10 message to all or a selected number of com- 

munication nodes in the mobile network. 

1 1 . The method of transmitting a data packet according 
to any of preceding Claims 5 to 1 0, the method fur- 
15 ther characterised by the step of: 

sending a mobile network prefix advertisement 
message by a mobile router at a top of a routing 
hierarchy in the mobile network to advertise 
20 said mobile network prefix; and 

determining by communication nodes in the 
same mobile network that they are located with- 
in the sending mobile router's mobile network. 

25 12. The method of transmitting a data packet according 
to any of preceding Claims, the method further 
characterised by the step of: 

sending an extended binding update message 
30 containing route infonnation only to communi- 

cation nodes outside of the sending communi- 
cation node's mobile network. 

13. A communication message (2600, 2700) having 
35 route infonnation that includes an ordered list of in- 
termediary addresses, for example, of intermediate 
mobile routers in a nested mobility scenario, be- 
tween a first communication node and a second 
communication node, for use in the method of any 

40 of preceding Claims 1 to 12. 

14. A communication message (2500) that includes a 
plurality of intemnediary routes or intermediary 
source routes corresponding to a respective plural- 

45 ity of mobile routers to be used to fonvard said data 
packet to said intended recipient. 

15. The communication message according to Claim 
14, wherein said message is a mobile network pre- 

50 fix advertisement message (2300) . 

16. A communication message including a request 
(2200, 2400) for a communication message accord- 
ing to Claim 14 or Claim 15. 

55 

17. A communication node comprising: 

an interface for communicating with other com- 
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munication nodes, for example in a mobile net- 
work; the communication node characterised 
by: 

a memory element storing an extended 
binding cache containing routes and/or 
source route information relating to a plu- 
rality of communication nodes, for example 
nodes in the mobile networic; 
a processor, operably coupled to said 
memory element, for generating a route, 
based on information stored in the extend- 
ed binding cache; and 
a transmitter, operably coupled to said 
processor, for delivering a data pact<et to 
an intended recipient via said route. 

18. A communication node comprising: 

an Interface for communicating with other com- 
munication nodes, for example in a mobile net- 
woric; the communication node characterised 
by: 

a receiver operably coupled to said inter- 
face, receiving an extended binding update 
message containing route infomiation re- 
lating to a communication node in the mo- 
bile networl<; and 

a processor, operably coupled to said re- 
ceiver, for generating a care of source 
route message, based on information con- 
tained in the extended binding update mes- 
sage. 

19. A storage medium (2800) storing care of source 
route infomnation, in accordance with any of the pre- 
ceding Claims. 

20. A method for building an extended binding cache at 
a first communication node, the method character- . 
ised by the steps of: 

receiving, from a second communication node, 
an extended binding update message Indicat- 
ing a plurality of intermediary addresses in a 
route for messages to reach said second com- 
munication node; 

comparing said Intemnediary addresses of said 
extended binding update message with inter- 
mediary addresses of the first communication 
node's route messages; 
extracting at least one subsequent route mes- 
sage of said second communication node, 
when said comparison fails to yield a match fol- 
lowing previous route matches, thereby gener- 
ating an extended binding cache entry indicat- 
ing an improved route to said second commu- 


nication node. 

21. A method for constructing and sending (700, 800, 
900) a care-of route advertising message at a mo- 
5 bile network node, the method characterised by 
the steps of: 

building (750, 850, 950) a care-of route adver- 
tisement message including a Care-of Route of 
10 said mobile network node; and 

sending (760, 860, 960) the care-of route ad- 
vertisement message to all nodes operably 
coupled to mobile network node; 

15 wherein said steps of building and sending are ini- 
tiated by one of the following: 

receiving (720) an advertisement message ac- 
cording to Claim 14 or Claim 15; or 
20 receiving (920) a request for an advertisement 

message according to Claim 1 6; or 
responding (820) to a time-out of an advertising 
message time. 

25 22. A method (1700, 1800, 1900) for constructing and 
sending mobile network prefix advertising message 
at a mobile router, the method characterised by the 
steps of: 

30 building (1725, 1815, 1920) a mobile network 

prefix advertising message including a mobile 
network prefix and a mobile network prefix 
length; and 

sending (1730, 1820, 1925) the mobile network 
35 prefix advertising message to all nodes opera- 

bly coupled to said mobile router; 

wherein said steps of building and sending are Ini- 
tiated by one of the following: 

40 

... . . receiving (1710) an mobile network prefix ad- 
vertising message according to Claim 1 5; or 
receiving (1910) a request for an mobile net- 
work prefix advertising message according to 
45 Claim 16; or 

responding (1 81 0) to a time-out of a mobile net- 
work prefix advertising message time. 

23. A storage medium (665) storing processor-iniple- 
50 mentable instructions for controlling a processor to 

cany out the method of any of claims 1 to 12, 20, 
21 or 22. 

24. Apparatus adapted to perform the method of any of 
55 any of claims 1 to 1 2 or 1 6. 

25. A communication unit comprising apparatus ac- 
cording to Claim 24. 
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26. A communication system comprising a communica* 
tion unit according to Claim 25 or apparatus accord- 
ing to Claim 26. 


10 


15 


20 


25 


30 


35 


40 


45 


50 


55 


18 


EP 1 376 973 A1 


105 



105 



19 


EP1 376 973A1 



20 


EP 1 376 973 A1 


370- 


CN2 BINDING CACHE 


MR2 PREFIX 


MRl PREFIX 


MR2 Coe 


MRl Coe 



21 


EP1 376 973A1 


TO NEXT ENTRY 
IN BINDING CACHE 


532 

MB3 PREFIX+ 
PREFIX LENGTH 


MR3 CARE OF 
ADDRESS 


536 


530 


522 


TO NEXT ENTRY /- 
IN BINDING CACHE^r^ 


534 


MB2 PREFIX+ 
PREFIX LENGTH 


MR2 CARE-OF 
ADDRESS 


526 


520 


512 


9^ 


524 


MRl PREFIX+ 
PREFIX LENGTH 


NO NEXT ENTRY- 


516 
X 


510 


MRl CARE-OF 
ADDRESS 


514 


-5J5 


-525 


-5/5 


FIG. S 


V 


500 


HOME LINK-2 


HOME UNK l 



MRl LINK 


652-- 

MRl. 

.CoA 

662^ 

MR2. 

_CoA 


MR2LINK- 



|lFRi| ^2J5 


660 


LFN2 1 ^565 


0 I MR1_CoA 


LFRl LINK^ 
670 


LFNl 


1^675 


22 


EP 1 376 973 A1 


START 



710 


a/(?-( start) 


INPUT: 

NEWCoR^ADVT \^720 
RECEIVED ON i/c_i 


820^ 


INPUT: PERIODIC 
CoR.ADVT_TMR 
HAS EXPIRED 


START PROCESS A [ ^730 
<^MNN_CoR HAS CHANGED?^ 


850" 


740 


YES 


BUILD CoR^ADVT 
AND INCLUDE 
MNN.CoR 

I 


k750 

760 

s 


SEND CoJl_i4DlT 
TO ALL NODES ON 
THE LINKS THROUGH ALL 
INGRESS INTERFACES OF 
MNN 


BUILD CoR_ADVT 
AND INCLUDE 
AfJVJV.CoJZ 


sea- 


SEND CoR.ADVT 
TO ALL NODES ON 
THE LINKS THROUGH ALL 
INGRESS INTERFACES OF 
MNN 


870" 


RESTART 
CoR.ADVT _TMR 

1 


START 


760 


700 



700 


INPUT: 
NEW CoR_REQ 
RECEIVED ON ifej 


^920 


^ifej IS 

INGRESS?^ 


JES 

BUILD CoR.ADVT 

AND INCLUDE 

MNN. 

.CoR 


NO 


925 


^950 


SEND CoR.ADVT 
TO SOURCE ADDRESS OF 
960H CoR.REQ THROUGH ifcj 


900 

FIG. 9 



980 


23 


EP1 376 973A1 



LFN2 care-of route==|MRlCoA-^MR2CoAfU565 


^1000 


24 


EP1 376 973A1 


(start process A) i^ 


INPUT: 
RECEIVED ON ifc_i 


I 


FIG. 11 

mo 


<ifc J IS EGRESS?^ )^ 


7/30 


A/0 


GET iVBIF.CoJI 
FROM CoJi_>lDKT 

I 


-■mo 


/Imnn is at 

\ (ON ifc_i 


»60 


A/0 





1170 


<JdNN_CoR'NEW.CoR)r^ 


MNN.CoR ;= (NEW^CoR, MNN^CoA)] 


NO 


1180 

_s_ 


MNN.CoR NEW_ CoR \ 


(jm PROCESS A}^ nso 


25 


EP 1 376 973 A1 


CSTABT^ 


1310 


1300- 


13 


INPUT: PERIODIC 
EBU_TMR(CNi) [^1320 
HAS EXPIRED 


1330' 


SEND AN EXTENDED BU 
CONTAINING MNN.CoR 

TO cm 

i 


INPUT: 
NEW CoR_ADVT 
RECEIVED ONifc_i 


1340^ 


RESTART 
EBU.TMR(Cm 


^1215 


START PROCESS Ai^l220 

p^— r 


<(mnN_CoR HAS CHANGED?^ 


A/0 


yES 


7225 


begin! \ 

V30 THROUGH ALL CNJ ^ '^'5*' 


I 


CURRENT CN FIRST CJV 


1-J2J5 


SEND AN extended BU 
CONTAINING MNN_CoR 
TO CURRENT CN 


1250 
i_ 


CURRENT CN ;■ NEXT CN | 


k7240 


CURRENT CN 
IS THE LAST ONE? 


\no 

'^1245 


YES 


1260 

s 


/mnn is at home 

\ ( ON ifc-i)? 


wo 


7255 



YES 


SEND AN extended BU 
containing MNN.CoR 
TO MJVJV's HA 


1200 


;2fi5 


26 


EP 1 376 973 A1 


INPUT: 
NEW CoR.ADVT 
RECEIVED ON ifc.i 

I 


^1215 


START PROCESS a[^1220 


1 


<jaNN.CoR HAS CHANGED?>- 


NO 


YES 


1225 


BEGIN: 
GO THROUGH ALL ON 

I 


1230 


CURRENT CN .= FIRST CN[^ 1235 


/ CURRENT CN 
< IS THE SAME MOBILE 

Xnetwork ASMjyy? 


^^1410 


SEND AN EXTENDED BU 
CONTAINING MNN_CoR 
TO CURRENT CN 


1^1240 


YES 


MNN IS AT HOME 
(ON ifci)? 


^1420 


SEND AN EXTENDED BU 
CONTAINING ONLY MNN.CoA 
TO CURRENT CN 


1430 


CURRENT CN 
IS THE LAST ONE? 


^ — 
^1245 


CURRENT CN ;= NEXT CN 


YES 


1440 

s 


t 


7250 


MNN IS AT HOME 
(ON ifc.j)? 


MO 


1255 



MNN'HA IS IN THE SAME 
MOBILE NETWORK AS MNN ?. 


YES 


1450 


\A/0 


YES 


SEND AN EXTENDED BU 
CONTAINING MNN.CoR 
lOMNN'sHA 


1260 


SEND AN EXTENDED BU 
CONTAINING \MNN.CoR\ 
TO MNN's HA 


7265 


1400 


27 


EP1 376 973A1 


START 



1510 


INPUT: PERIODIC 
EBU.Tmr(Cm) 
HAS EXPIRED 


1320 


CURRENT CN 
IS THE SAME MOBILE 
NETWORK ASAfAW?. 


1^1510 


SEND AN EXTENDED BU 
CONTAINING MNN^CoR 

TO cm 


\-1330 


YES 


MNN IS AT HOME 
(ON ife.i)? 


YES 


^1520 


RESTART 
EBV.Tmr(Cm) 


^1340 


1530 

s 


SEND AN EXTENDED BU 
CONTAINING OHLY \MNN.CoA\ 
TO CNi 


(start process B) ^^f.^f^ 

i 


INPUT: 

NEW.MOBILE.NETWORK.PREFIXJU}VT 
RECEIVED ON i/c.i 


^1620 


<^e.i IS EGRESS?> 
I C 
HO 


YES 


1630 


■1600 


1640 

__1 


GET NEW_MOBILE_NETWORK_PREFn 
FROM MOBILE_NETWORK_PREFIX.ADVT 



1650 


MNN's HOME ADDRESS ON ifc_i MATCHES 
NEW_MOBILE.NETWOBK_PREFIX 
ON NEW_M0BILE_NETW0RK_PREFIX_LENGTn7 


> 


YES 


MNN_M0BILE_NETWORS_PSEFIX := 
NEW.MOBILE_NETWOBK_PREFIX 

MliN_MOBILE_NETWORK_PREFIX_LENGTH:' 
WE W_ MOBILE_NETWORK.PREFIX_LENGTH 


(end PROCESS B) ^jf.jfj 


1660 


28 


EP 1 376 973 A1 


START 



1705 


INPUT: 

NEW^ MOBILE_NETWORK_PREFIX_AD VT 
RECEIVED ON ifc_i 


1720 


START PROCESS B 1^1715 


MNN_MOBILE_NETWORK_PREFIX AND/OR \nO 
MNN. MOBILE.NETWORK_PREFIX_LENGTH 
HAS CHANGED? 


YES 


BUILD MOBILE_NETWORK_PREFIX_ADVT 
AND INCLUDE MNN_MOBILE_NETWORK^PREFIX 
AND MNiV_ MOBILE_NETWORK_PREFIX_LENGTH 


■7 

1725 

-1730 


SEND MOBILE_NETWORK_PREF]X_ADVI 
TO ALL NODES ON THE LINKS THROUGH 
ALL INGRESS INTERFACES OF MSN 


END 


1735 


FIG. JL^ 


1700 


29 


EP1 376973A1 


1800 


INPUT: PERIODIC 
MOBILE_NETWORK_PREFn.ADVT.TMR 

HAS EXPIRED 


^1810 


BUILD MOBILE_NETWORK.PREFIX_ADVT 
AND INCLUDE MNNMBlLE^NETWORK_PREFIX 
AND MNN.MOBILE_NETWORK.PRBFn.LENGTH 


FIG. IS 


SEND MOBILE_NETWORK_PREFIX_ADVT 
TO ALL NODES ON THE LINKS THROUGH 
ALL INGRESS INTERF ACES OF MNN 

1 


1815 

\^1820 


RESTART 

jifOBiiE_JVEr]fOJiir_Pi?£m_iU)vr_TJifB 


START 



1905 


INPUT: 

NEW. MOBILE_NETWORK_PREFIX_SOL 
RECEIVED ON i/c_i 


1915 


I 


^1910 


1920 


" ^ifci IS INGRESS?^ -^ 


BUILD MOBILE_NETWORK_PREFIX_ADVT 
AND INCLUDE MNN_MOBILE_NETWORK_PREFIS 
AND MJVJV. MOBILE_NETWORK_PREFIX_LENGTH 


SEND MOBJLE_J\r£rTFOBir_PB£Fiy_AI)VT 

TO SOURCE ADDRESS OF 
NEW.MOBILE.NETWORK_PREFn.SOL 
THROUGH ifc_i 


7900 


(endX 


79JO 


30 


EP 1 376 973 A1 


INPUT: 
PACKET TO SEND TO 
N2 ADDRESS 

i 


^2020 


2000 


2040 


SEARCH FOR 
N2 ADDRESS [^2030 
IN EXTENDED BC 

I 


Fid. 20 


^ FOUND? > 


WO 


2050 

s 

JES 


2060 

SOURCE ROUTE THE PACKET THROUGH 
Nl-CoSR(TO N2 ADDRESS) 
TO m ADDRESS 


SEND THE PACKET TO 
m ADDRESS 



1 




(end). 


2070 


31 


EP 1 376 973 A1 



32 


EP 1 376 973 A1 


CM 


O 

o 

CM 
CM 


2^ 


CM 


33 


EP 1 376 973 A1 







'o 


CO 


1 


O 


O 



o 


[TATI 

[TYP 





O 

o 

CQ 




<; 







O 



o 




» 





o 

O 






o 

1 














o 



es 
o 

Cm 





a 


CO 




a> 


o 



o 


» 


u 

11 


00 




gu 




CM 


CN 



34 


EP 1 376 973 A1 



CM 


O 


I 

Ok 


IP 


35 


EP 1 376 973 A1 



36 


EP 1 376 973 A1 


2920 


2910 


Nl_CoR 


N1_CoR[l] 


Nl_CoR[2] 


Nl_CoR[...] 



Nl_CoR[...] 


N1_CoR[l] 


/ 
N2_CoR 

(FROM EXTENDED BINDING UPDATE) 


V IDENTICAL < 


2940-y^ 

■9* ^ 


2940 


Nl_CoR[l] 


N1_CoR[2] 


Nl_CoR[...] 


N1_CoR[.,.] 


N1_CoR[n] 



Nl_CoSR(toN2) 


N1_CoR[...] 


29J0 


N1_CoR[n] 


37 


EP 1 376 973 A1 


START 



3002 


INPUT; 
NEWN2.C0R 
(FROM EXTENDED BU 
SENT BY N2 TO N1) 


<JVi-Cofi IS EMPTY?> 


'3004 


YES 


< 


EBC CONTAINS AN\W0 
ENTRY FOR W2? 


JO/0- 


nV 


30oa 


YES 


REMOVE N2 ENTRY IN EBC 
{U.m^Co8R(toN2)) 


300B 


NO 


END: GO THROUGH 
ALL ADDRESSES 
mjCoUm AND NljCoRd) 


<JilJCoE IS EMPTY?> ) ^iVi_CogJi(toyajx=A2_CoflP 30T4 


3012 


3030 


3O22Ai:=0 


301$ 


EBC CONTAINS AN 
ENTRY FOR N2'i 


JOTS- 


ADD A J«8 ENTRY IN EBC 
WITH NijCo8R(to N2) 


YES 


3020 


UPDATED ENTRY IN EBC 
WITH Nl_CaSR(io N2) 


\i 1*11^3034 


BEGIN: 

GO THROUGH ALL ADDRESSES 
N2^CoB(i) IN N2.CoBm 
mjCoRd) IN HlJCiA 


I 


'J024 


J0J2 

J 


NO 


r:: ^Ni.CoB (i)'N2.CoRa)^ j02a 
N<r ^ I r \ 

5020 ^ 


Nl^CoRd) 
CIS THE LAST ADDRESS 
M_CoB ? 


NO 


N2.CoR(i) 
IS THE LAST ADDRESS 
NS^CoRl 


mjC6SR(toN2):' 
imjCoRm^N2jCoR(i*l)-,,. 
•*N2jCoR(nV -*li2.CoR(n)i 


RESS IN> 


YES 


END: 

GO THROUGH ALL ADDRESSES 

mjconm and mjcoRd) 


^3036 


EBC CONTAINS AN 
ENTRY FOR N2 7 


3044 

i 


1^3040 


YES 


ADD A N2 ENTRY IN EBC 
WITH mjCo8RttoN2) 
^ 

J042 


UPDATED ENTRY IN EBC 
WITH NKCoSRlto N2} 


38 


EP 1 376 973 A1 


European Patent 
Office 


EUROPEAN SEARCH REPORT 


Application Number 

EP 02 29 1523 


Category 


DOCUMENTS CONSIDERED TO BE RELEVANT 


Citation of document with indication, where appropriate* 
of re<evant passages 


Relevant 
to dam 


CLASSIFICATION OF THE 
APPLICATION (lntCi.7) 


EP 0 578 041 A (IBM) 

12 January 1994 (1994-01-12) 


* abstract * 

* figures 2-4 * 

♦ column 2, line 42 - column 3, line 55 * 

* column 6, line 16 - column 8, line 37 * 

♦ column 9, line 2 - column 10, line 28 * 

♦ column 11, line 27-42 * 


EP 1 189 411 A (TOKYO SHIBAURA ELECTRIC 
CO) 20 March 2002 (2002-03-20) 

* abstract * 

* figure 4 * 

* paragraphs * 0058!,' 0065!, * 0067! ♦ 


ERNST THIERRY: "Network Mobility Support 
In IPv6" 

THESIS DEPARTMENT OF MATHEMATICS AND 
COMPUTER SCIENCE OF UNIVERSITE JOSEPH 
FOURIER, 'Online! 

29 October 2001 (2001-10-29), pages 5-99. 

XP002215680 

Grenoble 

Retrieved from the Internet: 

<URL:www.1nr1a.fr> 

•retrieved on 2002-10-01! 

* figures 1.5,2.1,3.1-3.58,7.5,7.6 * 

« paragraphs 

•01.3!,*2.2.2.1!/3.1.1.1!-*3.1.1.5!,'07.1 
!, '7.1.3.1! * 


The present search report has been drawn up (or ati claims 


1-10. 
12-15, 
17-19, 
23-26 


H04L29/06 


11 

14-16, 
21-26 


11 

1-6,10, 
12-14, 
17-20, 
23-26 


TECHNICAL FIELDS 
SEARCHED ffntCLT) 


H04L 


Ptaceof saaitl 

MUNICH 


Oata of oomfMion of *ia 

1 July 2003 


Gabriel, C 


CATEGORY OF CrfED EXXXtMEffTS 

X ; pafllcutarty relevani if taken alone 

Y : pariictjtvty relevant tf combined wiib another 

document of the same category 
A : technological background 
O: noo-^wrttten disdosuie 
P:iiilefinedii 


T : theory or princ^te undertying the faivention 
E : eaitier paiem document, but published on. or 

after the BSngdate 
0 : document ciied in the appScalbn 
L : document ciled for othet reasons 

A : member of Oie same patent family, coiraspontft^ 


39 


EP 1 376 973 A1 


European Patem 
Office 


EUROPEAN SEARCH REPORT 


Application Number 

EP 02 29 1523 


DOCUMENTS CONSIDERED TO BE RELEVANT 


Categofy 


Ciiafion of document with indication, where appropriate. 
of relevant passages 


Relevant 
todaim 


CLASSmCATION OF THE 
APPtrCATION CmtCLT) 


UO 01 31822 A (TOSHIBA AMERICA RES INC 
; TELCORDIA TECH INC (US)) 
3 Hay 2001 (2001-05-03) 

* abstract * 

* figures 2,7 ♦ 

* page 3, line 15-20 * 

* page 8, line 15 - page 10, line 9 * 

PERKINS C E: "MOBILE NETWORKING IN THE 
INTERNET" 

MOBILE NETWORKS AND APPLICATIONS, BALTZER 
SCIENCE PUBLISHERS, BUSSUM, NL, 
vol. 3, 1998, pages 319-334, XP002939809 
ISSN: 1383-469X 

* abstract * 

* paragraphs 

•04.6! , '005.!,' !-'05. 51/009.! * 

HU Y-C ET AL: "Caching Strategies 1n 
On-Demand Routing Protocols for Wireless 
Ad Hoc Networks" 

MOBICOM. PROCEEDINGS OF THE ANNUAL 
INTERNATIONAL CONFERENCE ON MOBILE 
COMPUTING AND NETWORKING. XX, XX, 
6 August 2000 (2000-08-06), pages 
231-242, XP002215681 

* abstract * 

* figure I * 

* paragraphs '001. ! . '002. ! , *03.1! * 

~" -/- 


14-16, 
21-26 


1-13. 
23-^26 


17.19, 
20,23 


The present search report has been drawn up for an dalms 


TECHNICAL FIELDS 
SEARCHED (trtUCLT) 


MliNICK 


1 July 2003 


Gabriel, C 


CATEGORY OF CTTEO DOCUMENTS 

X : paiticutaHy reievant U tsSum atom 

Y : paiticulaify rdevanl if Donbitted w&h another 

document of tfta same categoy 
A : lectinoiogica] bacHground 
O : mn-wrtten dsdosuTe 
P : Intennediale document 


T : Iheoiy or pAntifto under^ng the taventkm 
E : eaifler paieni documeiti. out ptAOshed od. «f 

after (he fifing data 
D : document cied b> the appflcalion 
L : documem c8ed for oOierieasons 

A : insrnber of tfta same palef4 lajnay. coRS^p^^ 


40 


EP 1 376 973 A1 


European Patent 
Office 


EUROPEAN SEARCH REPORT 


Application Number 

EP 02 29 1523 


DOCUMENTS CONSIDERED TO BE RELEVANT 


Category 


Citation of document with Indication, where appropriate, 
of retevant passages 


Relevant 
todaim 


CLASSJHCATION OF THE 
APPUCATIQW {InLCLT) 


OKAJIMA I ET AL: "Architecture and mobile 

IPv6 extensions supporting mobile networks 

In mobile communications" 

VIC FALL 2001. IEEE 54TH. VEHICULAR 

TECHNOLOGY CONFERENCE. PROCEEDINGS. 

ATLANTIC CITY, NJ, OCT. 7-11, 2001, IEEE 

VEHICULAR TECHNOLGY CONFERENCE, NEW YORK, 

NY: IEEE, US, 

vol. 1 OF 4^ CONF. 54, 

7 October 2001 (2001-10-07), pages 

2533-2537, XP010562429 

ISBN: 0-7803-7005-8 

* abstract ♦ 

* page 2533. left-hand column, 
- right-hand column, paragraph 

* page 2534, left-hand column, 
paragraph * 

* page 2535, left-hand column, paragraphs 
3,4 » 

Section V. 

NARTEN T ET AL: "RFC 2461: Neighbor 
Discovery for IP Version 6" 
IETF REQUEST FOR COMMENTS, XX, XX, 
December 1998 (1998-12), pages 1-93, 
XP002198179 

* paragraphs '04.1!-'04.4! * 


14-16, 
18.21,22 


paragraph 3 
6 * 
last 


14-16 


TECHNICAL RELOS 
SEARCHED QtACLT} 


The present search report has been drawn up for all claims 


MUNICH 


Db|0«I eonplelron et twsasidt 

1 July 2003 


Gabriel, C 


CATEGORY OF CrTEO DOCUMENTS 

X : paiticularty relevant taken alone 

Y : paiticuiany relevant B oofrtUned with another 

document of the same category 
A : lechnologtcal background 
O : nonHMvilten disdosure 
P : intemedlaia documem 


T : theory or printiple undertying the invenlion 
£ : eaifjer patent docimient. twl putillshed on. or 

after the (iing date 
D : document cited in ttie appDeation 
L : docvmeni c2ed (or other reasons 

S : member dt the same patent fantily. ooiresponcfog 


41 


EP 1 376 973 A1 



European Patent 
Office 


EP 02 29 1523 


Application Number 


CLAIMS INCURRING FEES 


The present European patent application comprised at the tune of fSng mom than ten daims. 

□ Only part of the daims tiave been paid within the prescribed time Bmit The present European search 
report has tseen drawn up for the first ten claims and tor those claims for which claims fees have 
been paid, namely claiiTi(s}: 


□ No claims fees tiave been paid witttin t)e prescribed fime limit The present European search report lias 
been drawn up for the first ten daims. 


LACK OF UNITY OF INVENTION 


The Search Division considers that the present European patent appRcation does not comply with ttie 
tequiremenls of unity of invention and relates to several inventions or groups of inventions, namely: 


see sheet B 


All further search fees have been paid wilttin lhe fixed time limit The present European search report ha: 
been drawn up for all daims. 


□ As ail searchable claims could be searched without effOft justifying an additional fee. the Search Division 
(£d not invite payment of any additional tee. 


□ Only part of tt^ further search fees have been paid within the fpced time limit The present European 
search report has been drawn up for those parts of the European patent application which relate to the 
inventions in respect of which search fees have been psa6, namely claims: 


□ None of the further search fees have been paid within the fixed time limit. The present European search 
report has been drawn up for those parts of the European patent applicalion which relate to the invention 
lii:st mentioned in the daims* namely claims: 


42 


EP1 376 973A1 


Eiffopean Patent 
Offfica 


LACK OF UNITY OF INVENTION 
SHEETS 


EP 02 29 1523 


AppIIca&on Number 


The Search Division considers thdt the present European patent application does not oompty with the 
requirements of unity of invention and relates to several inventions or groups o1 inversions, namely: 

1. Claims: Claims 1-15, 18, 20, 21 and. 

In so far as referencing these claims, 
claims 23-26 


The use of a route message Including a list of Intermediary 
addresses for conveying routing information. 


2. Claims: Claims 16 and 22 and. 

In so far as referencing these claims, 
claims 23-26 


The use of a communication message including a request for a 
message having route information for obtaining routing 
Information quickly. 


3. Claim : 17 and 19 

The use of a storage medium for maintaining care of source 
information. 


43 


EP 1 376 973 A1 


ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 02 29 1S23 


This annex lists th& patent famO/ membersrelating to patent documents dted In the above-mentioned European search report. 
The members are as contained in the European Patent Office EDP fOe on 

The European Patent Office ts In no way liable for these pankmlars which are merely given for the purpose of infonnation. 

01-07-2003 


Patent document 
cited In search report 


Publication 


Patent famlty 
inembef(s) 


Publication 
date 


EP 0578041 


12-01-1994 US 
CA 
DE 
DE 
EP 
JP 
JP 


5442633 A 
2095447 Al 
69327019 01 
69327019 T2 
0578041 A2 
2637901 B2 
6104926 A 


15-08-1995 
09-01-1994 
23-12-1999 
31-05-2000 
12-01-1994 
06-08-1997 
15-04-1994 


EP 1189411 A 20-03-2002 JP 2002094558 A 29-03-2002 

EP 1189411 A2 20-03-2002 

US 2002031135 Al 14-03-2002 


UO 0131822 A 03-05-2001 WO 0131822 Al 03-05-2001 



u For more details about this annex : see Offida) Journal of the European Patent Office. No. 12/82 


44 


